You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I propose to move the golang.org/x/crypto/hkdf package into the standard library with the name crypto/hkdf. golang.org/x/crypto/hkdf would then be updated to just be a wrapper around crypto/hkdf.
I acknowledge that depending on golang.org/x/crypto/hkdf or crypto/hkdf doesn't make much difference in terms of usability, either the x/crypto package and the standard library promise backwards compatibility and are respected by the Go community. Yet, doing this move will bring two main benefits for the Go standard library and for the niche of users requiring FIPS 140 compliance:
crypto/tls uses golang.org/x/crypto/hkdf to implement TLS 1.3, and there are some Go forks out there that either already provide FIPS compliant TLS 1.3 via OpenSSL, or plan to do so in the near term. I suppose that Google will eventually also provide it, but this is out of this proposal. Adding this support would be much easier if crypto/hkdf was part of the standard library, in which case it could be patched to forward calls to crypto/internal/boring as needed.
hkdf is widely used outside the standard library. Users depending on it that also require FIPS 140 compliance will benefit from having it in the standard library as a package backed by BoringCrypto/OpenSSL/CNG, etc.
Worth noting that golang.org/x/crypto/hkdf API has remained the same for more than 5 years, and that its git log only contains 4 commits since it was added in 2014. It seems to already be in good shape, so I don't expect that moving it to the standard library would require much additional maintenance effort.
For completeness, this is the current golang.org/x/crypto/hkdf API that I'm proposing to add to the standard library:
// Expand returns a Reader, from which keys can be read, using the given// pseudorandom key and optional context info, skipping the extraction step.//// The pseudorandomKey should have been generated by Extract, or be a uniformly// random or pseudorandom cryptographically strong key. See RFC 5869, Section// 3.3. Most common scenarios will want to use New instead.funcExpand(hashfunc() hash.Hash, pseudorandomKey, info []byte) io.Reader// Extract generates a pseudorandom key for use with Expand from an input// secret and an optional independent salt.//// Only use this function if you need to reuse the extracted key with multiple// Expand invocations and different context values. Most common scenarios,// including the generation of multiple keys, should use New instead.funcExtract(hashfunc() hash.Hash, secret, salt []byte) []byte// New returns a Reader, from which keys can be read, using the given hash,// secret, salt and context info. Salt and info can be nil.funcNew(hashfunc() hash.Hash, secret, salt, info []byte) io.Reader
@golang/security
The text was updated successfully, but these errors were encountered:
I propose to move the golang.org/x/crypto/hkdf package into the standard library with the name
crypto/hkdf
.golang.org/x/crypto/hkdf
would then be updated to just be a wrapper aroundcrypto/hkdf
.I acknowledge that depending on
golang.org/x/crypto/hkdf
orcrypto/hkdf
doesn't make much difference in terms of usability, either thex/crypto
package and the standard library promise backwards compatibility and are respected by the Go community. Yet, doing this move will bring two main benefits for the Go standard library and for the niche of users requiring FIPS 140 compliance:crypto/tls
usesgolang.org/x/crypto/hkdf
to implement TLS 1.3, and there are some Go forks out there that either already provide FIPS compliant TLS 1.3 via OpenSSL, or plan to do so in the near term. I suppose that Google will eventually also provide it, but this is out of this proposal. Adding this support would be much easier ifcrypto/hkdf
was part of the standard library, in which case it could be patched to forward calls tocrypto/internal/boring
as needed.hkdf
is widely used outside the standard library. Users depending on it that also require FIPS 140 compliance will benefit from having it in the standard library as a package backed by BoringCrypto/OpenSSL/CNG, etc.Worth noting that
golang.org/x/crypto/hkdf
API has remained the same for more than 5 years, and that its git log only contains 4 commits since it was added in 2014. It seems to already be in good shape, so I don't expect that moving it to the standard library would require much additional maintenance effort.For completeness, this is the current
golang.org/x/crypto/hkdf
API that I'm proposing to add to the standard library:@golang/security
The text was updated successfully, but these errors were encountered: