Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: x/crypto/hkdf: Allow skipping the extract stage #28237

Closed
btoews opened this issue Oct 16, 2018 · 2 comments
Closed

proposal: x/crypto/hkdf: Allow skipping the extract stage #28237

btoews opened this issue Oct 16, 2018 · 2 comments
Labels
FrozenDueToAge Proposal Proposal-Accepted Proposal-Crypto Proposal related to crypto packages or other security issues
Milestone
Proposal

Comments

@btoews
Copy link

btoews commented Oct 16, 2018

RFC5869 suggests that the extract stage of HKDF's extract-and-expand process can be skipped if there is sufficient entropy in the input key material. Would it be worth providing a separate function for initializing the hkdf struct directly?

func NewNoExtract(hash func() hash.Hash, secret, info []byte) io.Reader
@gopherbot gopherbot added this to the Proposal milestone Oct 16, 2018
@FiloSottile FiloSottile added the Proposal-Crypto Proposal related to crypto packages or other security issues label Oct 16, 2018
@FiloSottile
Copy link
Contributor

This is also useful to TLS 1.3, so I'm going to add the following two APIs:

  • func Extract(hash func() hash.Hash, secret, salt []byte) []byte
  • func Expand(hash func() hash.Hash, pseudorandomKey, info []byte) io.Reader

pseudorandomKey is ugly to look at, but that's intentional, as it signals that this should have non-obvious properties to the user. The docs will make it clear it's not the thing you should use in most cases.

By the way, you say "can be skipped if there is sufficient entropy in the input key material", but the criteria is not the amount of entropy (which does not increase with the Extract step), but the distribution and length of the value.

@gopherbot
Copy link

Change https://golang.org/cl/144398 mentions this issue: hkdf: add Extract and Expand

@golang golang locked and limited conversation to collaborators Oct 25, 2019
c-expert-zigbee pushed a commit to c-expert-zigbee/crypto_go that referenced this issue Mar 28, 2022
@FiloSottile
hkdf: add Extract and Expand
780fe89 
RFC 5869, Section 3.3 suggests it might be sometimes appropriate to use
Expand without Extract, and it is reasonable to reuse (secret, salt)
with different info values, in which case the Extract can be performed
once as an optimization.

TLS 1.3 also needs direct access to both Extract and Expand.

pseudorandomKey is ugly to look at, but that's intentional, as it
signals that this should have non-obvious properties to the user. The
docs will make it clear it's not the thing you should use in most cases.

Fixes golang/go#28237

Change-Id: Ib43ae8cdde0663aa4752172c39aadfb0e1c35f10
Reviewed-on: https://go-review.googlesource.com/c/144398
Reviewed-by: Adam Langley <agl@golang.org>
c-expert-zigbee added a commit to c-expert-zigbee/crypto_go that referenced this issue Mar 29, 2022
@c-expert-zigbee
hkdf: add Extract and Expand
e3116b2 
RFC 5869, Section 3.3 suggests it might be sometimes appropriate to use
Expand without Extract, and it is reasonable to reuse (secret, salt)
with different info values, in which case the Extract can be performed
once as an optimization.

TLS 1.3 also needs direct access to both Extract and Expand.

pseudorandomKey is ugly to look at, but that's intentional, as it
signals that this should have non-obvious properties to the user. The
docs will make it clear it's not the thing you should use in most cases.

Fixes golang/go#28237

Change-Id: Ib43ae8cdde0663aa4752172c39aadfb0e1c35f10
Reviewed-on: https://go-review.googlesource.com/c/144398
Reviewed-by: Adam Langley <agl@golang.org>
c-expert-zigbee added a commit to c-expert-zigbee/crypto_go that referenced this issue Mar 29, 2022
@c-expert-zigbee
hkdf: add Extract and Expand
df775af 
RFC 5869, Section 3.3 suggests it might be sometimes appropriate to use
Expand without Extract, and it is reasonable to reuse (secret, salt)
with different info values, in which case the Extract can be performed
once as an optimization.

TLS 1.3 also needs direct access to both Extract and Expand.

pseudorandomKey is ugly to look at, but that's intentional, as it
signals that this should have non-obvious properties to the user. The
docs will make it clear it's not the thing you should use in most cases.

Fixes golang/go#28237

Change-Id: Ib43ae8cdde0663aa4752172c39aadfb0e1c35f10
Reviewed-on: https://go-review.googlesource.com/c/144398
Reviewed-by: Adam Langley <agl@golang.org>
LewiGoddard pushed a commit to LewiGoddard/crypto that referenced this issue Feb 16, 2023
@FiloSottile
hkdf: add Extract and Expand
f9c195c 
RFC 5869, Section 3.3 suggests it might be sometimes appropriate to use
Expand without Extract, and it is reasonable to reuse (secret, salt)
with different info values, in which case the Extract can be performed
once as an optimization.

TLS 1.3 also needs direct access to both Extract and Expand.

pseudorandomKey is ugly to look at, but that's intentional, as it
signals that this should have non-obvious properties to the user. The
docs will make it clear it's not the thing you should use in most cases.

Fixes golang/go#28237

Change-Id: Ib43ae8cdde0663aa4752172c39aadfb0e1c35f10
Reviewed-on: https://go-review.googlesource.com/c/144398
Reviewed-by: Adam Langley <agl@golang.org>
BiiChris pushed a commit to BiiChris/crypto that referenced this issue Sep 15, 2023
@FiloSottile
hkdf: add Extract and Expand
bcc22ef 
RFC 5869, Section 3.3 suggests it might be sometimes appropriate to use
Expand without Extract, and it is reasonable to reuse (secret, salt)
with different info values, in which case the Extract can be performed
once as an optimization.

TLS 1.3 also needs direct access to both Extract and Expand.

pseudorandomKey is ugly to look at, but that's intentional, as it
signals that this should have non-obvious properties to the user. The
docs will make it clear it's not the thing you should use in most cases.

Fixes golang/go#28237

Change-Id: Ib43ae8cdde0663aa4752172c39aadfb0e1c35f10
Reviewed-on: https://go-review.googlesource.com/c/144398
Reviewed-by: Adam Langley <agl@golang.org>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal Proposal-Accepted Proposal-Crypto Proposal related to crypto packages or other security issues
Projects
None yet
Milestone
Proposal
Development

No branches or pull requests
3 participants
@btoews @FiloSottile @gopherbot