2 ms·

> There is zero evidence It's about being cautious. If we want secure systems for the masses, we need to advance cryptographic defenses faster than we have pro

> There is zero evidence It's about being cautious. If we want secure systems for the masses, we need to advance cryptographic defenses faster than we have proofs the attackers are advancing. Most crypto we consider broken today "had zero evidence that anyone would ever break it" before it actually happened...

upofadown 5y ago
The aspect here is that we have zero evidence that the next breakthrough would allow the cracking of 2048 bit RSA and not, say, 4096 bit RSA. Chances are, any such breakthrough would allow a more general solution. See quantum computing for an example where this would be true. The inherent uncertainty of cryptography seems to cause people to want to do something, anything, in an attempt to decrease the uncertainty, even if there is no rational reason behind the approach.
tialaramex 5y ago
[Edited: This used to begin "However SSH keys enjoy forward secrecy" but on more consideration that's the wrong way to look at it anyway] The only role your SSH key plays (which is why you can use Ed25519) is to make signatures. So, if the government discovers next Thursday how to break my archaic RSA key, they don't magically get to read transcripts of SSH sessions they recorded, they only get some sort of attack that could help them to impersonate me on fresh connections after Thursday. Essentially the authentication step goes like this: You: I know the private key corresponding to this public key 123456, does that help? Server: (Examines authorized_keys list) That would work, prove you know that key You: <Signature of SSH setup transcript using private key> Server: Welcome southerntofu All this is happening inside an encrypted session. Your client (and remote servers) automatically negotiate the safest mutually intelligible session key agreement and encryption to set that up, independent from stuff like your personal keys.
mileza 5y ago
I think the same thing about SHA-1. It is possible to generate a collision with it, but it is costly, inefficient and practical. If you design software, then yes you should put mechanisms in place to replace older and less secure ciphers with new ones, and prefer and limit the ones you chose for some who are considered safe at the moment. But I don't think we should put red flags all over a cipher or a hashing functions because someone with unlimited resources and money managed to fool it once.

upofadown 5y ago

The aspect here is that we have zero evidence that the next breakthrough would allow the cracking of 2048 bit RSA and not, say, 4096 bit RSA. Chances are, any such breakthrough would allow a more general solution. See quantum computing for an example where this would be true. The inherent uncertainty of cryptography seems to cause people to want to do something, anything, in an attempt to decrease the uncertainty, even if there is no rational reason behind the approach.

tialaramex 5y ago

[Edited: This used to begin "However SSH keys enjoy forward secrecy" but on more consideration that's the wrong way to look at it anyway] The only role your SSH key plays (which is why you can use Ed25519) is to make signatures. So, if the government discovers next Thursday how to break my archaic RSA key, they don't magically get to read transcripts of SSH sessions they recorded, they only get some sort of attack that could help them to impersonate me on fresh connections after Thursday. Essentially the authentication step goes like this: You: I know the private key corresponding to this public key 123456, does that help? Server: (Examines authorized_keys list) That would work, prove you know that key You: <Signature of SSH setup transcript using private key> Server: Welcome southerntofu All this is happening inside an encrypted session. Your client (and remote servers) automatically negotiate the safest mutually intelligible session key agreement and encryption to set that up, independent from stuff like your personal keys.

mileza 5y ago

I think the same thing about SHA-1. It is possible to generate a collision with it, but it is costly, inefficient and practical. If you design software, then yes you should put mechanisms in place to replace older and less secure ciphers with new ones, and prefer and limit the ones you chose for some who are considered safe at the moment. But I don't think we should put red flags all over a cipher or a hashing functions because someone with unlimited resources and money managed to fool it once.