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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

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.