ublish their test vectors.
Regards,
Quynh.
From: "Torsten Schütze"
Sent: Tuesday, May 12, 2020 8:36 AM
To: Dang, Quynh H. (Fed)
Cc: Hugo Krawczyk ; c...@ietf.org ;
tls@ietf.org ; rs...@akamai.com
Subject: Aw: Re: [Cfrg] NIST crypto group and HKDF (and theref
re
> forgery. But then people naturally wanted to use hashes (as a “utility
> function” in Phillip’s terms) for a MAC. But hashes with message extension
> suffer from MAC forgery. Along came HMAC to the rescue, saving the day, and
> the rest is history. (To exaggerate
On Tue, May 12, 2020 at 12:31 PM Dan Brown wrote:
> Hi Hugo,
>
>
>
> Some curious molehill questions. Please take with a grain of salt.
>
>
>
> In short, does HKDF-Extract suffer from related-salt and repeated-IKM?
>
>
>
> To elaborate:
>
>
>
> Phillip raises a good point below about HMAC
; Salz, Rich
Subject: Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
On Mon, May 11, 2020 at 4:36 PM Hugo Krawczyk mailto:h...@ee.technion.ac.il> > wrote:
There is no flaw if you use HMAC and HKDF as intended. See details below.
One time pads aren't flawed if y
Gesendet: Dienstag, 12. Mai 2020 um 14:04 Uhr
Von: "Dang, Quynh H. (Fed)"
An: "Torsten Schütze" , "Hugo Krawczyk"
Cc: "c...@ietf.org" , "tls@ietf.org" ,
"rs...@akamai.com"
Betreff: Re: [Cfrg] NIST crypto group and HKDF (and therefo
d as expansion steps.
Regards,
Quynh.
From: "Torsten Schütze"
Sent: Tuesday, May 12, 2020 7:39 AM
To: Hugo Krawczyk
Cc: Dang, Quynh H. (Fed) ; c...@ietf.org ;
tls@ietf.org ; rs...@akamai.com
Subject: Re: [Cfrg] NIST crypto group and HKDF (and therefo
Hi Hugo, hi Quynh,
on Monday, 2020-05-11 Hugo Krawzcyk wrote:
> I haven't looked at the revisions. But in previous versions you needed lawyer
> skills to go through the language to see that RFC 5869 was indeed compliant
> with the NIST recommendation. It would be nice if this time it would
On Mon, May 11, 2020 at 4:36 PM Hugo Krawczyk
wrote:
> There is no flaw if you use HMAC and HKDF as intended. See details below.
>
One time pads aren't flawed if you use them right. When they become a two
time pad, there is a problem.
My point is that if we are developing schemes that are
> 27 . 28 . 29 Elaine Barker 30 Lily Chen 31 Computer Security Division 32 ..
> Information Technology Laboratory
> nvlpubs.nist.gov
>
> --
> *From:* Cfrg on behalf of Salz, Rich 40akamai@dmarc.ietf.org>
> *Sent:* Friday, May 8, 2020 4:21 PM
> *To:* tls@ietf.org ;
There is no flaw if you use HMAC and HKDF as intended. See details below.
The bottom line advise is: If you are using related (not random) salt
values in HKDF, you are probably using it with domain separation
functionality. In HKDF, domain separation is enforced via the info field
not the salt.
I will forward this to the official comment address as well.
I don't support making HKDF a NIST standard in its current form because
there is a flaw.
Consider the case in which the initial keying material is formed by
concatenating two items, the second of which is a variable length string.
As
Dear all.
I just now noticed the call for comment for SP-800-56c. Please note
the state-of-the-art paper
on seedless randomness extraction in the recent CRYPTO'19 paper by
Sandro Coretti, Harish Karthikeyan, Stefano Tessaro and myself:
"Seedless Fruit is the Sweetest: Random Number Generation,
12 matches
Mail list logo
