Have you ever wondered how long it would take to create a 32768 bit RSA key with ssh-keygen? Well, I did.
$ time ssh-keygen -t rsa -b 32768 -f ~/.ssh/tmp32768 -N foobar -q real 244m31.259s user 244m15.664s sys 0m4.736s
In other words, on my test system (AMD X2 CPU with 1.8 GHz per core) it took ca. 4 hours. This is likely very dependent on how much entropy you can get (and how fast), so take the numbers with a grain of salt. A second key with 32767 bits (one less) took 16 hours, for instance.
The resulting tmp32768 (private key) file is ca. 25 KB big, the tmp32768.pub (public key) file is 5 KB big.
There's likely no noticeable performance hit for ssh or scp AFAICS, as all data transfers are done with a symmetrical session key, not the RSA key itself. Only the initial connection "handshake" will take ca. 40 seconds longer...
And yes, 32768 is the maximum RSA key size you can currently create with OpenSSH, go file a bug report if that's not enough for you ;-) However, as I then noticed, this key will not actually work. When you put it in some authorized_keys file and try to login, the handshake will fail and the server-side will see the following error in /var/log/auth.log:
sshd[xxxxxx]: error: RSA_public_decrypt failed: error:04067069:lib(4):func(103):reason(105)
I first thought I found an off-by-one error, but the 32767 bit key (one bit less) didn't work either. After looking through the OpenSSH and OpenSSL code as well as the RSA_private_decrypt(3SSL) manpage a bit, I saw that OpenSSH uses the RSA_PKCS1_PADDING parameter. My current theory is thus that some padding is making the key not work. I'm now creating a key with 11 bits less bits than 32768, let's see what happens. For the record, a key with 16384 bits does work just fine.
Anyway, I'll probably report this as "bug" (more a theoretical than a practical problem, though) as ssh-keygen let's you generate RSA keys which will never work in practice...
how the .... am I supposed to tell GNOME to use or not use an HTTP proxy for specific applications?
Now guess what happens when I disable the HTTP proxy in Epiphany. It's disabled in Galeon, too. Enable it in Galeon, and Rhythmbox will use the proxy (thus slowing down huge downloads for no reason). Aargh.
Is it really so hard to have per-application settings? I mean, this isn't exactly rocket-science, right?
And yes, I do want to use all those applications at the same time. And no, I do not run a full GNOME desktop environment (I use IceWM, thanks), so I don't care about any GNOME-Desktop-Foo solutions — I just want each of those freaking applications to have their own settings.
If yes, please consider signing this online petition which asks the government to completely prohibit the usage of voting machines in Germany. Actually, you should sign this replacement petition, as the first one was getting "too big", a.k.a the software or server they use couldn't handle the sheer numbers of recorded votes anymore (ironic, isn't it?)...
Note: the deadline for the petition is today, i.e., November 28, 2006!
Ca. 45.000 people have signed already. If 50.000 signers are reached, there's sort of a guarantee that the government has to formally put this issue on their agenda (or something in that direction, I don't remember the exact details right now).
If you haven't followed the latest news regarding the voting machine issues, I urge you to get informed by reading the recent blog entries of Frank Rieger and Tim Pritlove (for example). The Chaos Computer Club (CCC) has a very good collection of information and further readings. Take a look.
A few days ago police in Poland arrested a 17 year old kid who ran a mini-farm of cannabis inside his PC. The PC was normally used but modded to contain a light source, and keep humidity and temperature at proper levels.
The kids these days...
(via Boing Boing)