[GTALUG] Netgear 5-port Gigabit switch -- $10 ?

[El Fontanero]

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