From: TLS <tls-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: Tuesday, January 11, 2022 4:01 PM To: Douglas Stebila <dsteb...@gmail.com> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Revised hybrid key exchange draft
… With that said, defense in depth is good. Does it help to have just a structured input, e.g., opaque KeyInput<0..2^16-1>; struct { KeyInput inputs<2..2^16-1>; } KeyScheduleInput; I don’t believe that the structured input idea would do much to frustrate the attack. The attack relies on the attacker controlling the initial part of the concatenated shared secret, and implementing a collision if one of the bytes of the shared secret he does not know is a specific value. What the structured input would do is set certain bytes of the initial part of the concatenated shared secret to known (to the attacker) values; that is, instead of the concatenated shared secret being: XX XX XX … XX XX XX YY YY … YY YY YY (XX are the bytes from the weak key exchange, YY being the ones from the strong one), It would look like 02 00 20 00 XX XX XX … XX XX XX 20 00 YY YY … YY YY YY (this example assumes both key inputs are 32 bytes long) As long as he can find collisions where those specific bytes are fixed to those set by the structured inputs in both blocks (that is, with the 02 00 20 00 XX XX XX … XX XX XX 20 00 pattern, with the differences being confined to the XX bytes), then the attack can proceed exactly as normal. Now, allowing the attacker less flexibility when setting up the collision would (one would expect) make finding collisions harder; however we can’t assume it makes them impractical. What would address the attack would be to pad the KeyInput (should they be of variable length) to a fixed maximum length (for example, the longest that key exchange algorithm can output). This would also address a weakness someone found in TLS 1.2, where the DH shared secret was effectively variable length (as the leading 0’s were stripped off), which could lead to a timing attack. Now, the attack that used that weakness relied on other properties of DH – however, that could also be used as precedence to forbid variable length shared secrets.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls