length of ciphers versus length of key

Question

ssh-keygen defaults to RSA (for SSH protocol 2) and a 2048 bit key.

At this description of ssh

         The supported ciphers
         are: 3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc, aes128-ctr,
         aes192-ctr, aes256-ctr, arcfour128, arcfour256, arcfour, blow-
         fish-cbc, and cast128-cbc.  The default is:

           aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,
           arcfour256,arcfour,aes192-cbc,aes256-cbc,aes128-ctr,
           aes192-ctr,aes256-ctr

Thus it appears ciphers are either 128 or 256 bit, if I infer from unitless numbers. What is the justification for the ciphers being shorter than the key?

Answer 1

That's the key length for RSA (asymetric encryption). It is used to establish the identity of the server and perform authentication and symmetric key exchange. It does not perform encryption of the connection.

The ciphers you depicted above are all symmetric, these are used to encrypt the connection. At least for AES I'm sure the maximum key length is 256 bits.

To give you a basic idea of how SSH works:

1. Generate a random session key
2. Encrypt this session key with the servers public and your private certificate
3. server decrypts the session key and a symmetric encryption is set up between the client and the server to send the data over. Since it is encrypted with the server's public key, only the server can read it. Since it is encrypted with your private certificate, the server knows it must have come from you (or more accurately the holder of the corresponding private key.)

If you want more information, there is a really nice explanation here.

Answer 2

You need to differentiate between key exchange function and cipher function. The key exchange happens as Lucas Kauffman told. Both parties use asymmetric crypto to verify their identity (or posession of the private identity part) and agree upon a session key which is used with a cipher function like AES or the other ciphers that you have shown.

As a rule of thumb you can remember: Asymmetric crypto needs way more computation time than symmetric one. This is why it is handy to use for key agreement but not for long run data encryption.

I was told in university (not that long ago) that theoretically 80 bits of enthropy (key length) are enough for todays computation power. Considered the only way of breaking a cipher is to brute force it. And if you consider that every bit you add to the key doubles the key space, then we are very fine with 128 or 256 bit keys for the next time to come.

Answer 3

"What is the justification for the ciphers being shorter than the key?"

As I understand it, the asymmetric keys need to have a mathematical relationship to each other (Private and Public) which severely limits the number of possibilities you can have, whereas the symmetric ciphers have a much larger 'per bit' supply of combinations. This site does a much better job of explaining it.

As per how to change what cipher-or the key length-SSH uses, I'm still searching. To change the asymmetric authentication key length, use ssh-keygen -b 4096 to create a new key with 4096 bits, do this in the /etc/ssh directory to update the server's key and create yourself a new key. Make sure you have direct access to the machine when changing keys, or you may lock yourself out. I've found you can go to 8192 bit (Overkill? I know not such a word!) before SSH won't accept them anymore, I've even pushed a Raspberry Pi to that length.