3 ms·

One problem with this article (that does not invalidate the main point that you should not reuse keys for different protocols) is using SSH authentication as an

by dfox 11y ago

One problem with this article (that does not invalidate the main point that you should not reuse keys for different protocols) is using SSH authentication as an example. In SSH what gets signed in publickey (and hostkey) authentication is not controlled by server (client). Instead of some random value provided by other side, signed data include session id that is derived from result of first DH key exchange and thus unpredictable to either side of connection.

sdevlin 11y ago
> signed data include session id that is derived from result of first DH key exchange and thus unpredictable to either side of connection The unpredictability of DH output depends on the group parameters and public key validation performed by the peer. If the group contains small subgroups, Eve can send an element of small order and predict the DH output with high probability. For example, this is one of the attack vectors for the triple handshake attack on TLS: https://www.secure-resumption.com/tlsauth.pdf https://www.secure-resumption.com/tlsauth.pdf.
- dfox 11y ago
  Which is mitigated in SSH by two things: 1) The DH group is negotiated by both peers from fixed list. 2) output of key exchange is hashed with various values that are not all controlled by same side of connection Also after reading the relevant part of RFC4253 I've found out that the session id is conceptually an output of key exchange, but in the DH case it's derived from contents of key exchange messages and not from the result itself (not that it makes much of an difference).
kentonv 11y ago
While having the message be servers specified makes an attack easier, it is not necessary. Ultimately all you need is two protocols that can be mistaken for each other. SSH's session ID appears as the first few bytes of the signed message, so all you need is to find a protocol which happens to ignore those bytes or otherwise happens to allow the attacker to specify them. This is not unusual -- SSH itself, IIRC, will ignore leading "comment" lines at the start of a connection (though this is not in a context that gets signed, but the point is ignoring a prefix is not uncommon).

by dfox 11y ago

sdevlin 11y ago

> signed data include session id that is derived from result of first DH key exchange and thus unpredictable to either side of connection The unpredictability of DH output depends on the group parameters and public key validation performed by the peer. If the group contains small subgroups, Eve can send an element of small order and predict the DH output with high probability. For example, this is one of the attack vectors for the triple handshake attack on TLS: https://www.secure-resumption.com/tlsauth.pdf https://www.secure-resumption.com/tlsauth.pdf.

dfox 11y ago
Which is mitigated in SSH by two things: 1) The DH group is negotiated by both peers from fixed list. 2) output of key exchange is hashed with various values that are not all controlled by same side of connection Also after reading the relevant part of RFC4253 I've found out that the session id is conceptually an output of key exchange, but in the DH case it's derived from contents of key exchange messages and not from the result itself (not that it makes much of an difference).

kentonv 11y ago

While having the message be servers specified makes an attack easier, it is not necessary. Ultimately all you need is two protocols that can be mistaken for each other. SSH's session ID appears as the first few bytes of the signed message, so all you need is to find a protocol which happens to ignore those bytes or otherwise happens to allow the attacker to specify them. This is not unusual -- SSH itself, IIRC, will ignore leading "comment" lines at the start of a connection (though this is not in a context that gets signed, but the point is ignoring a prefix is not uncommon).