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...
I've just updated my DIY secure pseudo-DDNS setup using ssh article/HOWTO a bit, in order to make it simpler to set up (no more extra scripts required) and a bit more secure (by using command= and no-port-forwarding,no-X11-forwarding,no-agent-forwarding in the /home/user/.ssh/authorized_keys file, for instance).
If you've considered employing such as solution please revisit the article for updated instructions.
Yay, finally! After many, many months Miro, a video/audio podcast downloading/viewing application, has entered Debian testing again yesterday. For a very long time one issue after the other kept Miro out of testing, partly serious application bugs, partly autobuilder issues and other stuff. I had almost given up hope, but luckily my 1.2.3-2 upload has now finally entered testing, just in time for the freeze...
The Underhanded C Contest is an annual contest to write innocent-looking C code implementing malicious behavior. In this contest you must write C code that is as readable, clear, innocent and straightforward as possible, and yet it must fail to perform at its apparent function. To be more specific, it should do something subtly evil.
This year's topic is Leaky Redaction:
Write a short, simple C program that redacts (blocks out) rectangles in an image. The user feeds the program a PPM image and some rectangles, and the output should have those rectangles blocked out.
Your challenge: write the code so that the redacted data is not really gone. Ideally the image would appear blocked-out, but somehow the redacted blocks can be resurrected.
The deadline for submissions is September 30th, 2008. Winners will get a $100 ThinkGeek gift certificate (plus eternal fame, of course).
In 2005 I took part in this contest together with Daniel Reutter which was really great fun. See underhanded2005.tar for our entry (the topic was "covert fingerprinting" in 2005) and the comments from the judges for our entry (as well as the other entries).
Today seems to be Firefox/Iceweasel 3 Bashing Day on Planet Debian, so let me join the fun :)
I agree with most other people that the default Firefox/Iceweasel 3 config is not ideal, so here's what I did to fix it. Some of these items improve performance, some remove annoyances, some remove privacy issues, some remove security issues. Not everything here may be desirable for people other than me.
Select "Edit / Preferences".
Open a new tab, enter "about:config" as URL and hit ENTER. Click the annoying "I'll be careful, I promise!" button. Uncheck "Show this warning next time" while we're at it.
browser.urlbar.matchOnlyTyped = trueto disable the new, annoying "AwesomeBar" URL bar feature (which is also a huge privacy risk).
browser.tabs.tabMinWidth = 60and
browser.tabs.tabMaxWidth = 60(needs a browser restart). You can even use less than
60if you don't need any text and an icon per tab is enough for you.
extentions.getAddons.showPane = false.
bidi.support = 0. You'll probably never need it, so reduce the number of potential bugs and security issues by disabling it.
browser.ssl_override_behavior = 2and
browser.xul.error_pages.expert_bad_cert = true(thanks Pierre Habouzit).
browser.tabs.closeButtons = 3in order to prevent accidental closing of tabs (no more Close buttons on each tab, only one global Close button on the right). Yes,
CTRL+Shift+Thelps in case it still happens.
network.prefetch-next = falseto prevent random prefetching of webpages which means wasting CPU cycles and bandwidth, as well as subtle privacy and security issues.
None. Don't even think about installing crap like the closed-source Flash player if stability or security are important to you. If you absolutely must watch YouTube videos, I recommend youtube-dl.
Use as few as possible. Every extention may have security problems or bugs, and can negatively affect performance etc.