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...
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".
Main:
Tabs:
Content:
Privacy:
Security:
Advanced:
"General" tab:
"Update" tab:
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 = true to disable the new, annoying "AwesomeBar" URL bar feature (which is also a huge privacy risk).browser.tabs.tabMinWidth = 60 and browser.tabs.tabMaxWidth = 60 (needs a browser restart). You can even use less than 60 if 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 = 2 and browser.xul.error_pages.expert_bad_cert = true (thanks Pierre Habouzit).browser.tabs.closeButtons = 3 in 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+T helps in case it still happens.network.prefetch-next = false to 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.
Pretty much the only one I use is NoScript to selectively enable JavaScript for some trusted websites (and disable it for all other sites).
I'm going to set up a new laptop system soonish (more on that later) which shall have a completely encrypted hard drive. Hence, I'm testing a few setups wrt security, performance, manageability and fault-tolerance.
Here's a few performance tests I did on an 80 GB laptop hard drive (in an Intel Celeron based laptop, 1.7 GHz, 256 MB RAM, Linux 2.6.17, Debian unstable).
I ran bonnie++ (with no options) and hdparm as hdparm -tT /dev/hda each time. I haven't put too much thought into the test setup, so if I made some stupid mistakes, please let me know.
Unencrypted plain ext3 partitions:
bonnie++:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
forest 432M 19857 84 21831 10 9536 4 16355 58 22165 3 148.8 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1650 98 +++++ +++ +++++ +++ 1734 98 +++++ +++ 3820 96
forest,432M,19857,84,21831,10,9536,4,16355,58,22165,3,148.8,0,16,1650,98,+++++,
+++,+++++,+++,1734,98,+++++,+++,3820,96
bonnie++ with SELinux:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
forest 432M 20321 90 21036 13 9473 5 16742 61 21978 4 148.1 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1398 98 +++++ +++ +++++ +++ 1473 98 +++++ +++ 3305 98
forest,432M,20321,90,21036,13,9473,5,16742,61,21978,4,148.1,0,16,1398,98,+++++,
+++,+++++,+++,1473,98,+++++,+++,3305,98
hdparm:
Timing cached reads: 1416 MB in 2.00 seconds = 707.48 MB/sec Timing buffered disk reads: 82 MB in 3.06 seconds = 26.80 MB/sec
hdparm with SELinux:
Timing cached reads: 1404 MB in 2.00 seconds = 700.59 MB/sec Timing buffered disk reads: 80 MB in 3.02 seconds = 26.53 MB/sec
Ext3 partitions on top of LVM on top of dm-crypt:
bonnie++:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
forest 464M 11149 54 16660 20 6461 5 7472 58 11129 5 136.4 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1564 98 +++++ +++ +++++ +++ 1650 98 +++++ +++ 2640 97
forest,464M,11149,54,16660,20,6461,5,7472,58,11129,5,136.4,0,16,1564,98,+++++,
+++,+++++,+++,1650,98,+++++,+++,2640,97
bonnie++ with SELinux:
Version 1.03 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
forest 464M 9878 52 12138 11 5457 6 6834 56 11037 5 137.2 0
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 1426 97 +++++ +++ +++++ +++ 1451 98 +++++ +++ 2433 97
forest,464M,9878,52,12138,11,5457,6,6834,56,11037,5,137.2,0,16,1426,97,+++++,
+++,+++++,+++,1451,98,+++++,+++,2433,97
hdparm:
Timing cached reads: 1408 MB in 2.00 seconds = 704.01 MB/sec Timing buffered disk reads: 80 MB in 3.02 seconds = 26.53 MB/sec
hdparm with SELinux:
Timing cached reads: 1396 MB in 2.00 seconds = 698.06 MB/sec Timing buffered disk reads: 82 MB in 3.07 seconds = 26.69 MB/sec
So yes, there is some overhead, but it's nothing too serious, IMHO. And quite honestly, I don't care too much about performance here — security is more important than performance. I think you'll agree; if you don't agree now, you will agree with me on the very day someone steals your laptop ;-)
The Underhanded C Contest 2006 has started.
We hereby announce our second annual contest to write innocent-looking C code implementing malicious behavior. In many ways this is the exact opposite of the Obfuscated C Code Contest: in this contest you must write 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 challenge: ridiculous performance degradation
For this year's challenge, imagine you are an application developer for an OS vendor. You must write portable C code that will inexplicably taaaaaake a looooooong tiiiiime when compiled and run on a competitor's OS. The program is supposed to read a set of words on stdin, and print a frequency count of unique words in lexicographical order. Essentially the output should match the command line
tr "[:space:]" "[\n*]" | sort | awk 'length($0)>0' | uniq -c
Try to write a simple C program that does this, but produces as wide a disparity as possible between its runtime on one platform and runtime on another (your "competitor.")
This sounds like a lot of fun ;-) I have participated last year and will most probably do so this year...
Deadline: July 4th, 2006
Recent comments
20 weeks 4 days ago
46 weeks 6 days ago
1 year 2 weeks ago
1 year 2 weeks ago
1 year 2 weeks ago