OK, so here's what crazy computer geeks come up with when they're bored of just sitting in the subway and staring out of the window.
Well, first you need a web server (duh). I decided to use lighttpd, as it's said to be small and memory-efficient (which sounded pretty important given what I was trying to do). Apache would probably not be a good choice here. Mind you, I have not done any benchmarks at all, I'm just guessing...
$ apt-get install lighttpd
Then, I wrote a little shell script containing a loop, which invoked lighttpd on port 1, 2, 3, 4, ..., 65535. That's it ;)
#!/bin/bash TMPDIR=/tmp CONFFILE="server.document-root = \"/var/www/\" index-file.names = ( \"index.html\" )" for ((i = 1; i < 300; i = i + 1)) do echo "+++ Starting web server on port $i" echo $CONFFILE > $TMPDIR/lighttpd.conf echo "server.port = $i" >> $TMPDIR/lighttpd.conf /usr/sbin/lighttpd -f $TMPDIR/lighttpd.conf rm -f $TMPDIR/lighttpd.conf done
I'm sure this can be optimized a lot, but it's sufficient for now, and it works.
You can test any of the web servers by running "
wget http://localhost:3556/" (for example). You can kill them all with
killall lighttpd. If you already run some other daemons on some ports, you cannot start a lighttpd on the same port, so you'll end up with fewer than 65535 servers.
In case you try this on your hardware, make sure you have lots of RAM and lots of swap. Don't run this on production hardware. Feel free to post your experiences in the comments.
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...
Bored? Feeling that artistic vibe? Why not make some music with your (HP ScanJet) scanner? Or at least watch a video of other people doing so (as soon as the slashdotting has stopped and the video is back, that is)?
Note to self: Add this to Crazy Hacks later, gotta run now.
Update 2006-01-23: Added this to Crazy Hacks (finally!).
(via hack a day)
Bored? Find yourself a paper clip and trade it for bigger things until you get a house.
This Internet thingy is... interesting at times.
(via Boing Boing)