From: TLS <[email protected]> On Behalf Of Eric Rescorla
Sent: Tuesday, January 11, 2022 4:01 PM
To: Douglas Stebila <[email protected]>
Cc: <[email protected]> <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
