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

[Douglas Stebila <[e-mail]>]

Length prefixing a variable length shared secret will not avoid this type of attack.  It doesn't arise from ambiguity about how long something is (which is what length prefixing resolves), it arises from being able to control where certain parts of the string land with respect to a hash function block boundary.

Douglas


> On Mar 25, 2022, at 3:58 PM, Blumenthal, Uri - 0553 - MITLL <[e-mail]> wrote:
> 
> What I had in mind was something like (described loosely 😉)
>  
> SS_i ::= <len_in_bytes> || <ss_i>
>  
> Len_in_bytes ::= INTEGER (1..65536) – field taking 4 bytes
> ss_i ::= symmetric shared secret obtained from the given KEM
>  
> SS_final = H(SS_1 || SS_2 || . . . || SS_n)
>  
> Sorry for sloppy handwaving, but I’m sure you understand what I mean.
>  
> TNX
> --
> V/R,
> Uri
>  
> There are two ways to design a system. One is to make it so simple there are obviously no deficiencies.
> The other is to make it so complex there are no obvious deficiencies.
>                                                                                                                                      -  C. A. R. Hoare
>  
>  
> From: Mike Ounsworth <[e-mail]>
> Date: Friday, March 25, 2022 at 12:34
> To: Uri Blumenthal <[e-mail]>, Ilari Liusvaara <[e-mail]>, LAMPS <[e-mail]>
> Subject: RE: [lamps] [EXTERNAL] Re: Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates
>  
> 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]> 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]
>     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.
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm