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

[Nimrod Aviram <[e-mail]>]

If it's envisioned that concatenate-and-hash is used with variable-length
shared secrets, padding the first secret such that it always occupies a
multiple of the hash function block size should stop attacks of this type
(APOP-style attacks).

I agree with Ilari (downthread) that truncating could have unexpected
consequences.

Also, variable-length KEMs indeed open the door to Raccoon-style attacks
that attempt to time the hash calculation in order to learn information
about the secret. I agree with Doulgas that this might merit some extra
care, esp. if using peculiar algorithms. At first glance, it seems that
requiring all KEMs to either be CCA-secure or to have fixed length should
prevent Raccoon-style attacks, but obviously this requires more careful
analysis.

best,
Nimrod



On Fri, 25 Mar 2022 at 16:30, Mike Ounsworth <[e-mail]>
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?
>
> ---
> Mike Ounsworth
>
> -----Original Message-----
> From: Douglas Stebila <[e-mail]>
> Sent: March 25, 2022 8:24 AM
> To: Mike Ounsworth <[e-mail]>
> Cc: Florence D <Florence.D=[e-mail]>; LAMPS <
> [e-mail]>; Nimrod Aviram <[e-mail]>
> Subject: [EXTERNAL] Re: [lamps] Security Consideration for
> draft-turner-lamps-nist-pqc-kem-certificates
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
>
> ______________________________________________________________________
> On Mar 25, 2022, at 9:14 AM, Mike Ounsworth <[e-mail]>
> wrote:
> >
> > > assuming that we use the NIST algorithms as they’re defined, the
> length of the shared secret shouldn't be ambiguous as it will be part of
> the parameter set for the KEM.
> >
> > Oh that’s good to know!
> > I saw that many (most? all?) of the remaining KEMs use SHAKE as their
> last internal step, so in theory they are variable-length, but if the NIST
> specs will fix the output length then that’s probably sufficient.
>
> All of the round 3 KEM finalists and alternate candidates have fixed
> length shared secrets, even if they happen to be using the extendable
> output function SHAKE internally while generating the shared secret.
>
> But it's not just the PQ shared secret that would need to be fixed
> length.  If one is concatenating two shared secrets and then hashing --
> H(ss_1 || ss_2) -- the concern arises when ss_1 is variable-length.  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.  For TLS 1.3 key
> exchange, the number of standardized curves is quite small so one can
> reasonably have confidence the scenario won't arise.  For general
> certificates with arbitrary algorithms, I can see there being a long tail
> of peculiar algorithms, some of which might be variable-length, so this
> scenario might merit some extra care.
>
> > At the TLS WG this week, Douglas Stebila presented on a known issue in
> the hybrid KEM combiner they’re proposing for TLS
> (draft-ietf-tls-hybrid-design): it gets into trouble if the attacker gets
> to play with the lengths of the shared secrets at runtime. Obvious
> solution: KEM codepoints need to fix the SS length in the spec so that it’s
> not variable at runtime.
>
>
> To be clear on the context here, there are additional requirements that
> have to be satisfied for there to be trouble, not the least of which is the
> ability to find collisions in the hash function used on concatenated
> secrets.
>
> Douglas
>
> >
> > The experts in this case are @Nimrod Aviram, and @Douglas Stebila.
> >
> > ---
> > Mike Ounsworth
> >
> > From: Florence D <Florence.D=[e-mail]>
> > Sent: March 25, 2022 8:09 AM
> > To: Mike Ounsworth <[e-mail]>; 'LAMPS' <[e-mail]
> >
> > Subject: [EXTERNAL] RE: [lamps] Security Consideration for
> draft-turner-lamps-nist-pqc-kem-certificates
> >
> > WARNING: This email originated outside of Entrust.
> > DO NOT CLICK links or attachments unless you trust the sender and know
> the content is safe.
> > > We’re putting together a draft which provides essentially the same
> combiner for hybrid CMS content encryption (yuck terminology hell. Florence
> D. please save us and write a terminology draft!).
> >
> > Very happy to write something.  I suspect the word hybrid is already so
> overloaded that agreeing on anything will be much more difficult but I’m
> happy to get started.
> >
> > > At the TLS WG this week, Douglas Stebila presented on a known issue in
> the hybrid KEM combiner they’re proposing for TLS
> (draft-ietf-tls-hybrid-design): it gets into trouble if the attacker gets
> to play with the lengths of the shared secrets at runtime. Obvious
> solution: KEM codepoints need to fix the SS length in the spec so that it’s
> not variable at runtime.
> > On the shared secret length, assuming that we use the NIST algorithms as
> they’re defined, the length of the shared secret shouldn't be ambiguous as
> it will be part of the parameter set for the KEM.  If we’re proposing doing
> something different then this probably merits some security analysis of its
> own.   I’ll defer to more experienced protocol designers on whether it’s
> worth encoding the length in the codepoint if it’s implicit from the
> scheme, I’m not sure of the precedent.
> >
> > Flo
> >
> > From: Spasm <[e-mail]> On Behalf Of Mike Ounsworth
> > Sent: 25 March 2022 11:17
> > To: 'LAMPS' <[e-mail]>
> > Subject: [lamps] Security Consideration for
> draft-turner-lamps-nist-pqc-kem-certificates
> >
> > The comment I was going to make at the mic:
> >
> > At the TLS WG this week, Douglas Stebila presented on a known issue in
> the hybrid KEM combiner they’re proposing for TLS
> (draft-ietf-tls-hybrid-design): it gets into trouble if the attacker gets
> to play with the lengths of the shared secrets at runtime. Obvious
> solution: KEM codepoints need to fix the SS length in the spec so that it’s
> not variable at runtime.
> >
> > We’re putting together a draft which provides essentially the same
> combiner for hybrid CMS content encryption (yuck terminology hell. Florence
> D. please save us and write a terminology draft!).
> > For that combiner to avoid the attack, I think we need Sean’s KEM OIDs
> draft to fix the shared secret length for each KEM that it specifies.
> >
> > So for now I think I’m just asking @Sean to throw a Security
> Consideration into his draft so we don’t forget that it’s important.
> >
> > ---
> > Mike Ounsworth
> > Software Security Architect, Entrust
> >
> > 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. This
> information is exempt under the Freedom of Information Act 2000 (FOIA) and
> may be exempt under other UK information legislation. Refer any FOIA
> queries to [e-mail]. All material is UK Crown Copyright ©
>
>