Re: [lamps] [EXTERNAL] Re: Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates

[Mike Ounsworth <[e-mail]>]

Thanks Uri.

Can you provide the concrete construction you have in mind when you say “include the length field in the hash”? I will add a note to our composite kem combiner draft, but I do not want to mis-interpret your suggestion.

---
Mike Ounsworth
Software Security Architect, Entrust

From: Spasm <[e-mail]> On Behalf Of Blumenthal, Uri - 0553 - MITLL
Sent: March 25, 2022 9:39 AM
To: Ilari Liusvaara <[e-mail]>; LAMPS <[e-mail]>
Subject: Re: [lamps] [EXTERNAL] Re: Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates


In general, I agree with the points Ilari made. However…



  *   I think it’s good to allow SS of variable length;
  *   When you allow variable length, you must include the length field into the hash;

  *   I don't think padding is necessary in this case;
  *   We should be careful regarding “max possible SS length”: while I don’t expect to ever see SS of, e.g., 56MB - I doubt it would stay at 32 or 48 bytes forever. I definitely don’t want to see “max possible SS len = 32”.



What’s the purpose of padding, if you included the length?



Re. RACOON attack – besides being pretty darn difficult to launch, it’s rather limited in applicability, IMHO – to the point I don’t really care. Besides, offhand, it isn’t applicable to NIST KEMs.



Thanks

--

V/R,

Uri





On 3/25/22, 09:50, "Spasm on behalf of Ilari Liusvaara" <[e-mail] on behalf of [e-mail]<mailto:[e-mail][e-mail]>> wrote:



    On Fri, Mar 25, 2022 at 01:30:28PM +0000, Mike Ounsworth wrote:

    > > So if your scenario envisions concatenating a traditional

    > (RSA/FFDH/ECC) shared secret and a PQ shared secret, one would want

    > to be sure the first component of the concatenation is not variable

    > length.

    >

    > Another good point!

    >

    > Thinking out loud: does padding solve the problem?

    >

    > H(ss_1 || ss_2 || .. || ss_n)

    >

    > if ss_i are each padded / truncated to, say, the security level of

    > the underlying hash function, does that work?



    One could solve the issue for variable length SS by adding a length

    field and padding to the maximum possible SS length. I think truncating

    is a bad idea, and could interact badly with some oddball KEMs.



    However, using KEMs with variable-length SS seems like a bad idea

    anyway. E.g., see the TLS RACCOON attack.





    -Ilari



    _______________________________________________

    Spasm mailing list

    [e-mail]<mailto:[e-mail]>

    https://www.ietf.org/mailman/listinfo/spasm

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.