ecryptfs-add-passphrase returns sig [d395309aaad4de06] for test

Right now I am a bit annoyed, because I have read the installation manuals for ecryptfs.
Most of them point to something like:

$ echo -n test | ecryptfs-add-passphrase
Inserted auth tok with sig [d395309aaad4de06] into the user session keyring
$ echo d395309aaad4de06 >> ~/.ecryptfs/secret.sig

basicly you later tell mount which passphrase to use via ecryptfs_fnek_sig=d395309aaad4de06,ecryptfs_sig=d395309aaad4de06

Maybe I am totally stupid, but for me, for the moment it looks as if signature actually means CHECKSUM. And it looks like this one is even worse than the one in your /etc/shadow. It may get better if your password is actually long compared with that checksum, but I would guess: most user passwords are not.

However I would be happy to learn that I was concerned for nothing.

brought nat64 to live

I just brought my first ever NAT64 up and running!

64 bytes from 64:ff9b::808:808: icmp_seq=501 ttl=57 time=1.42 ms
64 bytes from 64:ff9b::808:808: icmp_seq=502 ttl=57 time=1.48 ms
64 bytes from 64:ff9b::808:808: icmp_seq=503 ttl=57 time=1.50 ms
64 bytes from 64:ff9b::808:808: icmp_seq=504 ttl=57 time=1.43 ms
64 bytes from 64:ff9b::808:808: icmp_seq=505 ttl=57 time=1.36 ms
64 bytes from 64:ff9b::808:808: icmp_seq=506 ttl=57 time=1.51 ms
64 bytes from 64:ff9b::808:808: icmp_seq=507 ttl=57 time=1.55 ms
64 bytes from 64:ff9b::808:808: icmp_seq=508 ttl=57 time=1.45 ms
64 bytes from 64:ff9b::808:808: icmp_seq=509 ttl=57 time=1.53 ms
64 bytes from 64:ff9b::808:808: icmp_seq=510 ttl=57 time=1.35 ms
64 bytes from 64:ff9b::808:808: icmp_seq=511 ttl=57 time=1.35 ms
64 bytes from 64:ff9b::808:808: icmp_seq=512 ttl=57 time=1.37 ms
64 bytes from 64:ff9b::808:808: icmp_seq=513 ttl=57 time=1.56 ms

it can ping googles nameserver now.
V6 only infrastructure is coming.

using gnupg as a privacy guard

Two days ago I cleaned up my key management.
I created new gnupg keys and I figured out that gnupg is able to
deal with many more things than I thought of today.

You can use the Keys in you GPG storage to authenticate your ssh logins.
You can use the Keys for signing and ancrypting with both PGP and S/MIME

The GPG Agent keeps your keys painlessly locked away when you are not
using them for a while, but I do not have to enter my passphrase every
minute just to check my mail.

There is only one Option that I really miss: I want to authenticate
against Facebook, Google and others via using GnuPG, it is the
obvious next step. That means a Webbrowser who is aware of Gnupg and
a multipart signed mime post request. There are rumors that browsers
already have such a thing, but I was not able to find anything on the

So my private keys are now saver than before.
But lets start from scratch:

  • everyone uses electronic signatures, on webpages and for your eBanking
  • most people do know nothing about electronic signatures
  • not knowing is is dangerous

If you don’t know anything about Public Key and Signatures you definately
watch this:

An electronic signature is the other way round, you
encrypt private and decrypt public.

How easy is that? The only big issue is, that you have to keep your keys save.

So far, cu next time. Oh by the way, my new GnuPG Key is:

  • ID: 5F94E76B Keygrip: 977A0623F543190A41D7DE2A0D297B023E9868DD
Hack Attack

Security is a Bastard! Only two weeks ago, I did some major upgrades to my
internet server system. I improved especially my root passwords to a 6 digit
random generated one, hoping that it would take a few years to get all the
combinations done with that 3 seconds delay. WRONG WRONG WRONG, but my old
setup was even worse.

It took them 14 Days, on a system with only ssh open! how? Because I was a
naive. The MaxSessions parameter did misslead me a bit to belive that it means
connections but a session is not a connection, so hey, lets open a thousand
connections, and every connection trys 3 passwords, much faster!

So what did I do to prevent this from happening again:

  • Setting the PermitRootLogin back to without password
  • creating a special user who provides me access to su so I can get root in case of key loss
  • the special user has no obvious name, you can guess it.
  • 8 character random generated passwords
  • adding the following iptables rule:

iptables -A INPUT -p tcp -m tcp –dport 22
–tcp-flags FIN,SYN,RST,ACK SYN
-m connlimit –connlimit-above 10
–connlimit-mask 32 –connlimit-saddr
-j REJECT –reject-with icmp-port-unreachable

And that as a default on all systems. This will work until the next one comes along.

se ya.

so far for the bike

Note the Fatique crack.
I am heading off with a car now.

Starting for a motorbike holiday to croatia on thursday

I am starting to a 3 week holiday to croatia this thursday. The Bike will be a Track T800CDI.
I will also do some Ham Radio Operations, so stay tuned, you may hear something from DD5TT aka OE1SRC.

I will also post a travel report here.

Very odd perl experiences

Sometimes really odd things happen:

I am still testing if this perl expression:

my $obj=eval “Some::Object->new()”;

may be responsible for serious segmentation faults within perl for AIX.
pls stay tuned.

my UnUn for vertical antennas

Yesterday during a few drinks after our regular CW operators meeting in Vienna I told a friend how I wind Baluns (yes I know this one is an UnUn)
So here is a picture first:


I wind this by rolling some wire usually with 4 windings per coil over my Hand. I then fix that Wire ring with insulation tape. depending on how
long it should last I add plugs.

I use this UnUn usually together with a 6,5 or 10 m antenna wire and some Antennatuner as near as posible to the UnUn.


Usually 1:9 transmission is good enough to get good reports even with QRP Power on the 80m band.

The UnUn you see in the first picture also has a connection for 1:4 and 1:16 transmission, as shown in the next circuit diagram:


I am using this UnUn on almost all of my mobile operations. and it seems to have a good performance, however I would not try to
place it on a metal plate.

yet another key

This time it is from the Ukraine, I got it on a flea market in Altlengbach last weekend.


I bought it because of that really HUGE antisparking filter box below that key, and really,
as I thought. it is exactly 70mm x 120 mm which is happily the size of for example a small MA12

It is as far as I have googled a Soviet TKF Key manufactured between 1988 and 1992 by
Cherkassy Telegraph Equitment. I wonder what they plan to key with that. But the key has a
good feeling and will surly key a MA12 as mentioned above.

picture of the cw fieldday in bruck

Here a late picture of the CW fieldday in Bruck/Leitha where the participants of the course in which
we learned CW made a fieldday in the end of July where we started using our new skills.


Previous Page · Next Page