5 ms·

I am not convinced they are very different models. My argument: An attacker can save the encrypted SSH traffic going over an insecure channel, then hold the tr

• heavenlyhash 9y ago
  Yes. It is, forgive me for being blunt, nearly completely wrong. For starters, there's two different kinds of keys in use: symmetric and asymmetric. The ratio of "bits" to "strength" is completely different for the two categories. Asymmetric keys are typically only used to handle identity, then bootstrap a selection of symmetric keys (which are faster to use, generally); and then the symmetric keys used are typically based on Diffie Hellman key exchange, which is a whole 'nother ball of wax. Which bits you have to hold onto, and what you get when you compromise them, is not a flat field. Compromising the asymmetric keys used for identity at the beginning of communication means you can forge that identity in the future; but it doesn't necessarily mean you get to compromise other communications made with yet other keys which were merely agreed upon under the situational aegis of those asymmetric keys at a previous date.
• cesarb 9y ago
  With encrypted SSH traffic, there are normally three kinds of keys involved. The traffic is encrypted with per-connection symmetric keys, usually 256 bits. These keys are obtained through a Diffie–Hellman key exchange or similar, which uses per-connection randomly-generated keys. Finally, the long-term "SSH key" is used to sign these randomly-generated keys (and other things). If you hold the traffic until 2030 and want to decrypt it, you have to break either the symmetric keys, or the key exchange. Breaking the "SSH key" would allow you only to forge a new signature, but that doesn't help decrypting past traffic. That's the difference between the models: a key used for encryption, once broken, allows you to decrypt. A key used for signing, once broken, allows only forgery. And for SSH, forgery must be done while the forged key is still accepted (known_hosts or authorized_keys).
• tialaramex 9y ago
  Google (Perfect) Forward Secrecy There's a mathematical trick (actually these days several different ones, but the original idea is the same) which lets two people agree on a number without either of them saying what the number is OR any witnesses knowing what it is by watching the conversation. If you struggle with high school mathematics look for videos which demonstrate this trick using mixing paint, so you're not distracted by mathematics you don't understand. This trick is routinely used in realtime communications (HTTPS, SSH, secure messaging protocols) to make a throw away transient key [actually usually two and sometimes four] used only for one conversation. Once the communication is over, both parties throw away their transient keys, and even somebody who knows the long term keys can never find out what they were because of Forward Secrecy.
• e12e 9y ago
  In addition / supplement to what @heavenlyhash says: Gnupg cannot do a diffie hellman key exchange to set up the session/symmetric key: one party unilaterally generates a random symmetric key (eg: aes key), encrypts the session key with the recipient's public (asymmetric, eg: RSA) key, the message with the symmetric key and sends both cipher texts as the message. A passive attacker can store this, and will only need to crack/gain access to the recipient's private key, to recover the symmetric key, and then the message. Active/online protocols can use a key exchange: today that typically involves ephemeral (elliptic curve) diffie-hellman. The exchange is authenticated with the asymmetric key - but the session keys are independent of these "permanent" keys. So the eg: RSA key is used to make sure you're playing "guess the number I'm thinking of (the random symmetric session key)" with the intended recipient, and not an active attacker - but when the session key is thrown away, there's no way to recover it for either of the participants or a passive attacker. See also: https://lwn.net/Articles/572926/ https://lwn.net/Articles/572926/