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.

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

x/crypto/salsa20: keystream loop in amd64 implementation after 256GiB #30965

Closed
FiloSottile opened this issue Mar 20, 2019 · 3 comments

Comments

Projects
None yet
3 participants
@FiloSottile
Copy link
Member

commented Mar 20, 2019

If more than 256 GiB of keystream is generated, or if the counter otherwise grows greater than 32 bits, the amd64 implementation will first generate incorrect output, and then cycle back to previously generated keystream. Repeated keystream bytes can lead to loss of confidentiality in encryption applications, or to predictability in CSPRNG applications.

The issue might affect uses of golang.org/x/crypto/nacl with extremely large messages.

Architectures other than amd64 and uses that generate less than 256 GiB of keystream for a single salsa20.XORKeyStream invocation are unaffected.

This issue was discovered and reported by Michael McLoughlin.

@gopherbot gopherbot added this to the Unreleased milestone Mar 20, 2019

@gopherbot

This comment has been minimized.

Copy link

commented Mar 20, 2019

Change https://golang.org/cl/168406 mentions this issue: salsa20/salsa: fix keystream loop in amd64 assembly when overflowing 32-bit counter

justincormack added a commit to justincormack/swarmkit that referenced this issue Mar 21, 2019

Update x/crypto for salsa fix
This fixes golang/go#30965

This should not break any update, as we should not be encrypting more than
256GB data, as we only use secretbox for encrypting Raft values.

Signed-off-by: Justin Cormack <justin.cormack@docker.com>

justincormack added a commit to justincormack/swarmkit that referenced this issue Mar 21, 2019

Update x/crypto for salsa fix
This fixes golang/go#30965

This should not break any update, as we should not be encrypting more than
256GB data, as we only use secretbox for encrypting Raft values.

Signed-off-by: Justin Cormack <justin.cormack@docker.com>
@sidhax

This comment has been minimized.

Copy link

commented May 3, 2019

Do we have CVE or this is being treated as non-security bug ?

@sidhax

This comment has been minimized.

Copy link

commented May 10, 2019

CVE has been assigned to this https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11840. Please make sure to get CVE for a security fix in future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.