Add optional support for AEGIS encryption #900
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
AEGIS is a new family of authenticated encryption algorithms that offers stronger security, higher usage limits, and better performance than AES-GCM. This pull request adds support for a new `-aegis` command-line flag, allowing AEGIS-128X2 to be used as an alternative to AES-GCM on CPUs with AES acceleration. It also introduces the ability to use ciphers with different key sizes. More information on AEGIS is available here: - https://cfrg.github.io/draft-irtf-cfrg-aegis-aead/draft-irtf-cfrg-aegis-aead.html - https://github.com/cfrg/draft-irtf-cfrg-aegis-aead gocryptfs -speed speed on Apple M1: AES-GCM-256-OpenSSL 3718.79 MB/s AES-GCM-256-Go 5083.43 MB/s (selected in auto mode) AES-SIV-512-Go 625.20 MB/s XChaCha20-Poly1305-OpenSSL 1358.63 MB/s (selected in auto mode) XChaCha20-Poly1305-Go 832.11 MB/s Aegis128X2-Go 11818.73 MB/s gocryptfs -speed speed on AMD Zen 4: AES-GCM-256-OpenSSL 5215.86 MB/s AES-GCM-256-Go 6918.01 MB/s (selected in auto mode) AES-SIV-512-Go 449.61 MB/s XChaCha20-Poly1305-OpenSSL 2643.48 MB/s XChaCha20-Poly1305-Go 3727.46 MB/s (selected in auto mode) Aegis128X2-Go 28109.92 MB/s
./benchmark.bash./benchmark.bash -aegisI'm not convinced that this benchmark is very representative, though, as actual I/O is the limiting factor. The system CPU usage is significantly reduced when using AEGIS, though, which matter on real workloads. |
|
FYI Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz; with AES-GCM acceleration |
rfjakob
reviewed
Feb 27, 2025
internal/cryptocore/cryptocore.go
Outdated
| @@ -98,7 +109,7 @@ func New(key []byte, aeadType AEADTypeEnum, IVBitLen int, useHKDF bool) *CryptoC | |||
| { | |||
| var emeBlockCipher cipher.Block | |||
| if useHKDF { | |||
| emeKey := hkdfDerive(key, hkdfInfoEMENames, KeyLen) | |||
| emeKey := hkdfDerive(key, hkdfInfoEMENames, keyLen) | |||
There was a problem hiding this comment.
I think you downgrade EME to AES-128 here when aegis is used
There was a problem hiding this comment.
How about defining a dedicated EmeKeyLen constant? That would avoid confusion between the different key lengths.
There was a problem hiding this comment.
Done. This should fix the issue with EME.
rfjakob
added a commit
to rfjakob/aegis
that referenced
this pull request
Feb 27, 2025
4 KiB is interesting because it is the default page size on Linux, and also the block size that gocryptfs (a disk encryption tool) uses. gocryptfs is contemplating adding AEGIS support ( rfjakob/gocryptfs#900 ). Output now looks like this: $ go test -bench . goos: linux goarch: amd64 pkg: github.com/ericlagergren/aegis cpu: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz BenchmarkSeal16B_128L-4 12179401 97.09 ns/op 164.80 MB/s 0 B/op 0 allocs/op BenchmarkOpen16B_128L-4 11123548 104.7 ns/op 152.75 MB/s 0 B/op 0 allocs/op BenchmarkSeal1K_128L-4 4735476 253.1 ns/op 4045.21 MB/s 0 B/op 0 allocs/op BenchmarkOpen1K_128L-4 4614565 259.0 ns/op 3953.60 MB/s 0 B/op 0 allocs/op BenchmarkSeal4K_128L-4 1685662 712.3 ns/op 5750.17 MB/s 0 B/op 0 allocs/op BenchmarkOpen4K_128L-4 1667968 719.5 ns/op 5692.93 MB/s 0 B/op 0 allocs/op BenchmarkSeal8K_128L-4 867411 1327 ns/op 6175.61 MB/s 0 B/op 0 allocs/op BenchmarkOpen8K_128L-4 858153 1333 ns/op 6143.63 MB/s 0 B/op 0 allocs/op BenchmarkSeal16K_128L-4 460386 2543 ns/op 6441.87 MB/s 0 B/op 0 allocs/op BenchmarkOpen16K_128L-4 458068 2556 ns/op 6409.65 MB/s 0 B/op 0 allocs/op BenchmarkSeal16B_256-4 12555355 95.04 ns/op 168.35 MB/s 0 B/op 0 allocs/op BenchmarkOpen16B_256-4 11600582 102.5 ns/op 156.05 MB/s 0 B/op 0 allocs/op BenchmarkSeal1K_256-4 3595903 336.3 ns/op 3045.34 MB/s 0 B/op 0 allocs/op BenchmarkOpen1K_256-4 3511225 340.0 ns/op 3011.56 MB/s 0 B/op 0 allocs/op BenchmarkSeal4K_256-4 1000000 1056 ns/op 3878.99 MB/s 0 B/op 0 allocs/op BenchmarkOpen4K_256-4 1000000 1046 ns/op 3914.79 MB/s 0 B/op 0 allocs/op BenchmarkSeal8K_256-4 572815 2007 ns/op 4080.76 MB/s 0 B/op 0 allocs/op BenchmarkOpen8K_256-4 586015 1989 ns/op 4119.45 MB/s 0 B/op 0 allocs/op BenchmarkSeal16K_256-4 295207 3930 ns/op 4168.82 MB/s 0 B/op 0 allocs/op BenchmarkOpen16K_256-4 303639 3878 ns/op 4224.89 MB/s 0 B/op 0 allocs/op PASS ok github.com/ericlagergren/aegis 26.662s
|
FYI looks like https://github.com/ericlagergren/aegis Correction: ericlagergren/aegis AEGIS-128L is the same speed as go-libaegis AEGIS-128X2. (4K benchmark added via ericlagergren/aegis#16) |
|
https://github.com/aegis-aead/libaegis benchmark: AEGIS-128X2 being slower than AEGIS-128L means my CPU is too old (Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz) I guess. |
|
On the vast majority of server and desktop CPUs, including on Apple Silicon, 128X2 is generally the fastest. You are right that 128L is currently faster on older CPUs that don't support AVX2. An implementation trick will eventually minimize the difference. So, if we want to only support one variant, 128X2 looks like a decent default. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
AEGIS is a new family of authenticated encryption algorithms that offers stronger security, higher usage limits, and better performance than AES-GCM.
This pull request adds support for a new
-aegiscommand-line flag, allowing AEGIS-128X2 to be used as an alternative to AES-GCM on CPUs with AES acceleration.It also introduces the ability to use ciphers with different key sizes, as well as the ability to compile
gocryptfswithout CGO out of the box, without having to explicitly pass thewithout_opensslandwithout_aegistags.I believe it would be a great addition, but I understand if it can't be merged.
More information on AEGIS is available here:
$ gocryptfs -speed speed # on Apple M1:$ gocryptfs -speed speed # on AMD Zen 4:with
export CC='clang -O3 -march=native':