On 27/03/16 10:56 PM, James Knott wrote:
I thought ssh used a public/private key system, at least when used passwordless. I have to generate a public/private key pair and place the public key on the servers I connect to and keep the private key on my computer. Also, Cisco gear supports ssh with RSA keys. --- Talk Mailing List talk@gtalug.org https://gtalug.org/mailman/listinfo/talk
SSH uses public/private keys for a few things: 1. Host ID: As has been said already, if you are presented (via SSH) a signature made from a private host key whose public key you have and trust, you have a cryptographically secure ID of the peer. 2. Session key exchange - host keys of server and client (peers), using the also-mentioned Diffie Hellman algorithm and friends, are used to (independently) create (the same) shared secret. The secret never goes out over the wire in any form. 3. Optionally, authenticate the client with a (different) public/private key. The server has the user's public key, *only* the client has his corresponding private key. Alternatively, punt up to the OS to do a password challenge. 4. Session encryption - using the shared secret created in 2. and using one of the AES family of block ciphers or similar. The ciphers used here have changed a lot over time. DES56 was good as long as a modest network of Playstations couldn't brute-force it. AES (Rijndael) is a better scrambler and is used with more bits (128 to 256). RSA, for example, is not used to encrypt the whole session because it is computationally much more expensive, and would ultimately, over a large communication, provide a good lot of raw data with which to brute-force the key. And yes, SSH can create a new session key periodically for the same reason. Every 2^28 packets is recommended. Many of the plaintext "leakages" that have come up in the vulnerability publications in the past decade or so have not been as a result of weakness in RSA or AES, but in the implementation of the protocol in which they are used. For example, if an attacker were able to inject known errors in the length field an AES-CBC transmission and analyse the timing of the error return, he might get 32 bits or so of plaintext in ~2^18 tries. Each one of which terminated the SSH session. A weakness, yes, but not a very useful one. Back to the idea that knowledge of specific payload contents might help in decryption / plaintext recovery: These modern scrambling algorithms (ciphers) don't provide that kind of opportunity. The theory is that they are not reversible without the 128, 192, of 256-bit key itself. So a brute force attack on the encrypted data would still be necessary. All that you gain from some (or even general) knowledge about the original payload is that you know when you have hit on the key. *Anything* other than complete noise is almost certainly the original plaintext. But by then all the stars have gone out anyway. Unless the Playstation of the future is like Deep Thought. Or you got lucky (2^-256 ?) Cheers, Mike