4 ms·

Security is not binary. In this case it depends on whether disclosing your identity to the servers you connect to is a problem in your threat model. Saying "th

Security is not binary. In this case it depends on whether disclosing your identity to the servers you connect to is a problem in your threat model. Saying "they are public so it's ok" is technical oversimplification.

clinta 11y ago
It's not binary, but if your security depends on your public key being secret, something else must be wrong. It's the same as someone who depends on their IP addresses being secret. That's not something you can count on, and your security would be better served by designing your infrastructure with the assumption that it's totally public information.
- RaleyField 11y ago
  > public key The word public is just a name for a kind of key defined in the field of cryptography and doesn't necessary hold the same connotation in application protocols that use public key cryptography. One example would be ephemeral public key that would have to be kept private to be able to retain forward secrecy (although in such schemes DH is usually used). Consider as well this situation that is closer to SSH. Suppose that you are MS dev working on NT kernel that by night also want to anonymously contribute to Linux. Obviously both camps would not like you to do that for fear of copyright infringement but OpenSSH shouldn't betray you anonymity that could be reasonably expected. It's imaginable that only one public crypto key pair would be needed to authenticate the server if password authentication is used for the client. The user doesn't expect the client software to silently generate key pair, much less that the same pair is used for every domain because the pair is not strictly needed. Although the user should inform himself how the software works a good software similarly shouldn't work in ways that are reasonably unexpected to people that are familiar with the domain. Ideally, if OpenSSH developers can't really foresee it working any other way OpenSSH should at least explicitly inform the user which public key will be used in connection before it is established in order to not assume the consent of poorly informed users.
hobarrera 11y ago
> Saying "they are public so it's ok" is technical oversimplification. It's not. The whole idea of the scheme is that you can publish them everywhere with no risk.
- dchest 11y ago
  OMG, people! "Public" in "public key" doesn't mean that you should share it with the whole world, it's just because it's an antonym of "private key", meaning that the other party you want to communicate with doesn't need to have a pre-shared secret key with you. Other party may be the whole world, but may be not. How public key is used is up to a protocol and threat model: it may as well be secret, and yes, in some protocols and threat models security can depend on public key being secret, and it's not wrong, and not "security by obscurity".
- oleganza 11y ago
  In case of Bitcoin pubkeys you don't want to publish them anywhere for privacy reasons (that turn into real physical security reasons once you have enough BTC). Also, notice how pubkeys are normally hidden under hashes and revealed only at spending time. This drastically limits attacks on ECC if/when some weakness in curve math is discovered. And if quantum computer is invented tomorrow, people can safely transition funds to a new signature scheme by introducing 2-phase commitments to safely reveal (now crackable) ECDSA pubkey after another transaction was made with commitment to concrete signature (preventing double-spend attempts using a cracked key).

clinta 11y ago

It's not binary, but if your security depends on your public key being secret, something else must be wrong. It's the same as someone who depends on their IP addresses being secret. That's not something you can count on, and your security would be better served by designing your infrastructure with the assumption that it's totally public information.

RaleyField 11y ago
> public key The word public is just a name for a kind of key defined in the field of cryptography and doesn't necessary hold the same connotation in application protocols that use public key cryptography. One example would be ephemeral public key that would have to be kept private to be able to retain forward secrecy (although in such schemes DH is usually used). Consider as well this situation that is closer to SSH. Suppose that you are MS dev working on NT kernel that by night also want to anonymously contribute to Linux. Obviously both camps would not like you to do that for fear of copyright infringement but OpenSSH shouldn't betray you anonymity that could be reasonably expected. It's imaginable that only one public crypto key pair would be needed to authenticate the server if password authentication is used for the client. The user doesn't expect the client software to silently generate key pair, much less that the same pair is used for every domain because the pair is not strictly needed. Although the user should inform himself how the software works a good software similarly shouldn't work in ways that are reasonably unexpected to people that are familiar with the domain. Ideally, if OpenSSH developers can't really foresee it working any other way OpenSSH should at least explicitly inform the user which public key will be used in connection before it is established in order to not assume the consent of poorly informed users.

hobarrera 11y ago

> Saying "they are public so it's ok" is technical oversimplification. It's not. The whole idea of the scheme is that you can publish them everywhere with no risk.

dchest 11y ago
OMG, people! "Public" in "public key" doesn't mean that you should share it with the whole world, it's just because it's an antonym of "private key", meaning that the other party you want to communicate with doesn't need to have a pre-shared secret key with you. Other party may be the whole world, but may be not. How public key is used is up to a protocol and threat model: it may as well be secret, and yes, in some protocols and threat models security can depend on public key being secret, and it's not wrong, and not "security by obscurity".
oleganza 11y ago
In case of Bitcoin pubkeys you don't want to publish them anywhere for privacy reasons (that turn into real physical security reasons once you have enough BTC). Also, notice how pubkeys are normally hidden under hashes and revealed only at spending time. This drastically limits attacks on ECC if/when some weakness in curve math is discovered. And if quantum computer is invented tomorrow, people can safely transition funds to a new signature scheme by introducing 2-phase commitments to safely reveal (now crackable) ECDSA pubkey after another transaction was made with commitment to concrete signature (preventing double-spend attempts using a cracked key).