3 ms·

Interest article, but overlooks SPEKE, which solves problem #1. There is another protocol for authenticated and integrity protected key exchange, one that solv

Interest article, but overlooks SPEKE, which solves problem #1. There is another protocol for authenticated and integrity protected key exchange, one that solved both the problem of authenticity and integrity attacks, but I cannot recall it. Hoping someone else remembers it.

_1tan 2y ago
HMAC?
- PeterWhittaker 2y ago
  No, though HMACs can play a role. It was a protocol developed specifically for establishment of secure, encrypted, authenticated, and integrity-protected sessions. I've been racking my brain trying to remember (rarely accessed memories from ~27 years ago). The basic challenge is that unless authenticity, key exchange, and integrity are managed simultaneously during session establishment, there are attacks possible against whatever was omitted. There was a protocol developed at that time that did all of the above as part of session establishment, but I don't remember it really taking off (IIRC, it was patent-encumbered, and that was an obstacle to adoption).
ekr____ 2y ago
> Interest article, but overlooks SPEKE, which solves problem #1. Well, sort of. At a high level there are two scenarios: 1. The endpoints have had no prior contact. 2. The endpoints have had some prior opportunity to establish shared state. The common version of case (1) is the Web, where the client has the server's identity (i.e., a domain name). When the client connects to the server, the server has to prove its identity, specifically a binding between its name and its public key. That's where certificates come in because they allow the server to prove [0] its identity to a third party who when vouches for that attestation. The case where the endpoints have had an opportunity to establish shared state is different. There are basically three settings: - The shared state is one side's public key. In this case, you can (mostly) use the same kinds of authenticated key establishment protocols as before, just without the certificate. This is how SSH works. - The shared state is a high entropy secret (a pre-shared key). In this case, you can use it to bootstrap up to a shared key by authenticating the endpoints. TLS 1.3 provides such a PSK mode. - The shared state is a low entropy secret (a password). This last case is challenging because in the obvious protocol where you use it like a PSK an attacker can record a single protocol run and then exhaustively search the password space. The solution here is what's called a password authenticated key agreement (PAKE) protocol, which resists this kind of attack. SPEKE is one such protocol, though most of the interest now is in newer protocols like OPAQUE or SPAKE2+. There are proposals to bind these to TLS (https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/ https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/) but they don't really work for the Web (https://educatedguesswork.org/posts/password-proto/#password-authenticated-key-agreement https://educatedguesswork.org/posts/password-proto/#password...). [0] For some value of prove. Terms and conditions may apply.

_1tan 2y ago

HMAC?

PeterWhittaker 2y ago
No, though HMACs can play a role. It was a protocol developed specifically for establishment of secure, encrypted, authenticated, and integrity-protected sessions. I've been racking my brain trying to remember (rarely accessed memories from ~27 years ago). The basic challenge is that unless authenticity, key exchange, and integrity are managed simultaneously during session establishment, there are attacks possible against whatever was omitted. There was a protocol developed at that time that did all of the above as part of session establishment, but I don't remember it really taking off (IIRC, it was patent-encumbered, and that was an obstacle to adoption).

ekr____ 2y ago

> Interest article, but overlooks SPEKE, which solves problem #1. Well, sort of. At a high level there are two scenarios: 1. The endpoints have had no prior contact. 2. The endpoints have had some prior opportunity to establish shared state. The common version of case (1) is the Web, where the client has the server's identity (i.e., a domain name). When the client connects to the server, the server has to prove its identity, specifically a binding between its name and its public key. That's where certificates come in because they allow the server to prove [0] its identity to a third party who when vouches for that attestation. The case where the endpoints have had an opportunity to establish shared state is different. There are basically three settings: - The shared state is one side's public key. In this case, you can (mostly) use the same kinds of authenticated key establishment protocols as before, just without the certificate. This is how SSH works. - The shared state is a high entropy secret (a pre-shared key). In this case, you can use it to bootstrap up to a shared key by authenticating the endpoints. TLS 1.3 provides such a PSK mode. - The shared state is a low entropy secret (a password). This last case is challenging because in the obvious protocol where you use it like a PSK an attacker can record a single protocol run and then exhaustively search the password space. The solution here is what's called a password authenticated key agreement (PAKE) protocol, which resists this kind of attack. SPEKE is one such protocol, though most of the interest now is in newer protocols like OPAQUE or SPAKE2+. There are proposals to bind these to TLS (https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/ https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/) but they don't really work for the Web (https://educatedguesswork.org/posts/password-proto/#password-authenticated-key-agreement https://educatedguesswork.org/posts/password-proto/#password...). [0] For some value of prove. Terms and conditions may apply.