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

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

Along the same lines – how about “defending in depth” against block ciphers vulnerable to known-plaintext attacks and digital signatures that are easily forgeable, etc. etc.?

 

I understand the need to publish papers, but there got to be a limit in how far one pushes the assumptions.

--

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: Spasm <[e-mail]> on behalf of Uri Blumenthal <[e-mail]>
Date: Monday, March 28, 2022 at 09:20
To: Douglas Stebila <[e-mail]>
Cc: LAMPS <[e-mail]>, Ilari Liusvaara <[e-mail]>, Mike Ounsworth <[e-mail]>
Subject: Re: [lamps] [EXTERNAL] Re: Security Consideration for draft-turner-lamps-nist-pqc-kem-certificates

 


Length prefixing a variable length shared secret will not avoid this type of attack.


Would you mind clarifying - what attack/type-of-attack you mean?

 

https://github.com/nimia/kdf_public#readme

 

Thanks!

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.


Now you know where your 32-byte part of the string lands. Variable length would allow moving where your part of the string lands, somewhat. Still, so what? I don’t see a viable attack (assuming a decent hash function).

 

That's the whole point of this scenario -- that one is not assuming a decent hash function.

 

Bending over backwards to support screwed-up hash functions does not seem worth it in this day and age. We do know now how to construct good hashes.

 

TNX

 

 

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


_______________________________________________
Spasm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/spasm