performance

Creating 32768 bit RSA keys for fun and profit

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...

Configure Firefox/Iceweasel 3 to be more secure / usable / bearable

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.

General

  • Disable the bookmarks toolbar via "View / Toolbars / Bookmarks Toolbar", nobody needs that and we save some screen space. Remove all pre-defined bookmarks while we're at it.
  • Select "View / Toolbars / Customize".
    • Add the "New Tab" button/icon right after the "Home" button. This is probably the most-used button (for me at least) and it's not available per default...
    • Click "Use Small Icons", there's no reason to waste screen space.
    • Remove the Google search bar (useless).
    • Now move all icons and the URL bar into the menu bar (I'm not kidding). After that you can disable the nagivation toolbar via "View / Toolbars / Navigation Toolbar" and save even more screen space.

Preferences

Select "Edit / Preferences".

Main:

  • Select "When Iceweasel starts: Show a blank page".
  • Set "Home Page" to whatever you see fit.

Tabs:

  • Enable "Always show the tab bar".

Content:

  • At the right-hand side of "Enable JavaScript" click "Advanced" and uncheck all checkboxes. JavaScript stuff shouldn't need to do any of those operations.
  • Uncheck "Enable Java". Nobody needs this crap and it's a huge security risk.

Privacy:

  • Disable "Keep my history for xyz days" completely. Huge privacy risks.
  • Disable "Remember what I enter in forms and the search bar". Huge security and privacy risks, almost no gain.
  • Disable "Remember what I've downloaded". Huge privacy risks.
  • Uncheck "Accept third-party cookies".
  • Choose "Keep until: I close Iceweasel".
  • Click "Show Cookies" and remove all of them.
  • Enable "Always clear my private data when I close Iceweasel". Click "Settings" and check all items. You want to purge everything when closing Iceweasel.

Security:

  • On the right-hand side of "Warn me when sites try to install add-ons" click "Exceptions" and remove all exceptions.
  • Disable "Tell me if the site I'm visiting is a suspected attack site". Useless crap, possibly a privacy issue.
  • Disable "Tell me if the site I'm visiting is a suspected forgery". Useless crap, possibly a privacy issue.
  • Disable "Remember passwords for sites". This is a huge security risk, never ever enable it!

Advanced:

  • "General" tab:

    • Enable "Warn me when web sites try to redirect or reload the page".
    • Disable "Check my spelling as I type". Useless, annoying crap, which probably even impacts performance.
  • "Update" tab:

    • Disable "Automatically check for updates to: Installed Add-ons".
    • Disable "Automatically check for updates to: Search Engines".
    • Select "When updates to Iceweasel are found: Ask me what I want to do".
    • about:config

      Firefox/Iceweasel 3 screenshot

      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.

      • Set browser.urlbar.matchOnlyTyped = true to disable the new, annoying "AwesomeBar" URL bar feature (which is also a huge privacy risk).
      • Browser tabs are way too huge for my taste (thus only very few fit on the screen). Fix it with 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.
      • Disable the annoying, flashing auto-search stuff when you select "Tools / Add-ons / Get Add-ons": Set extentions.getAddons.showPane = false.
      • Set bidi.support = 0. You'll probably never need it, so reduce the number of potential bugs and security issues by disabling it.
      • Self-signed certificate handling is annoying, so fix it with: browser.ssl_override_behavior = 2 and browser.xul.error_pages.expert_bad_cert = true (thanks Pierre Habouzit).
      • Set 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.
      • Set 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.

      Plugins

      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.

      Extensions

      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).

Benchmarking an encrypted dm-crypt/LVM/ext3/SELinux hard drive with bonnie++ and hdparm

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:

  • Extra partitions for /, /boot, /usr, /var, /tmp, /home, and swap (no LVM).
  • Optionally, SELinux enabled on that system (targeted policy in permissive mode).

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:

  • One partition which is encrypted using dm-crypt (aes-cbc-essiv:sha256 mode, AES, 256 bit key size)
  • On top of that an LVM2 system, with extra partitions for /, /boot, /usr, /var, /tmp, /home, and swap.
  • Optionally, SELinux enabled on that system (targeted policy in permissive mode).

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

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

Syndicate content