Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This change adds a package, chacha20poly1305, which implements the ChaCha20-Poly1305 AEAD from RFC 7539. This AEAD has several attractive features: 1. It's naturally constant time. AES-GCM needs either dedicated hardware or extreme effort to be fast and constant-time, while this design is easy to make constant-time. 2. It's fast on modern processors: it runs at 1GB/s on my IvyBrige system. 3. It's seeing significant use in TLS. (A change for crypto/tls is forthcoming.) This change merges two CLs: https://go-review.googlesource.com/#/c/24717 https://go-review.googlesource.com/#/c/26691 I took the amd64-optimised AEAD implementation from the former because it was significantly faster. But the structure of the change is taken from the latter. This version will be checked into x/crypto. This package will then be vendored into the stdlib so that it can be used from crypto/tls. Change-Id: I5a60587958b7afeec81ca1091e603a7e8517000b Reviewed-on: https://go-review.googlesource.com/30728 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
- Loading branch information
594708b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the commit history of this code was lost, shouldn't the asm be attributed to @vkrasnov?
594708b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commit message says:
and it certainly wasn't the intention not to credit anyone. If you would like a more explicit notice in the assembly file I can certainly do that.
594708b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No big deal, these things happen. An explicit notice in the assembly of the authorship (commit author or otherwise) would be nice.
594708b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @agl, any mention is very much appreciated. I am just glad that you will be using this code. We have been using it for a while now.
I also have a similar implementation for arm64, but can't port it to goasm, due to lack of NEON instructions. Is there an ETA for NEON support?
594708b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See this change.
As for NEON in arm64, I'm not terribly familiar with Go on ARM but it appears that this is just something that hasn't been implemented yet.
(Although there would be a little more to it because ARM, unlike Intel, doesn't provide a CPUID instruction. Rather information about CPU support for instructions is provided in the aux vector, given by the kernel at process start. Thus some plumbing is probably required for that.)
594708b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome? Thanks @agl