Codecov Report

❌ Patch coverage is 91.25000% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.18%. Comparing base (10bd10a) to head (19bc50b).
⚠️ Report is 1 commits behind head on master.

@@            Coverage Diff             @@
##           master     #789      +/-   ##
==========================================
+ Coverage   82.04%   82.18%   +0.13%     
==========================================
  Files         111      111              
  Lines        6501     6490      -11     
==========================================
  Hits         5334     5334              
+ Misses        766      759       -7     
+ Partials      401      397       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

BTW - all the ciphers are tested by the end-to-end tests in e2e/e2e_test.go

I'll have a look on Monday.

It also seems like the new record header for DTLS 1.3 won't cause too much trouble/change.

Great @theodorsm . I think i’ll leave the chacha20poly addition outside of this PR and keep only refactors here. Then i’ll open a new PR with full support for chacha20poly ciphersuite.

Will also be easier to review that way.

This PR is now just a refactor of common code (in preparation to add ChaCha20-Poly1305 support, which will also use the same underlying aead encrypt()/decrypt(). cc:// @theodorsm @JoTurk @Sean-Der

Note to self, for later:

I've found that I can make all AEAD crypto primitives even faster by having a single re-usable buffer for nonces in encrypt, and another re-usable buffer for nonces in decrypt instead of using buffer pools, e.g.:

type aead struct {
	localAEAD     cipher.AEAD
	remoteAEAD    cipher.AEAD
	localWriteIV  []byte
	remoteWriteIV []byte
	tagLength     int

	encryptNonceBuf []byte // reusable buffer for encryption
	decryptNonceBuf []byte // reusable buffer for decryption
}

The numbers are really significant:

• CBC: 4-11% faster
• CCM: 8-22% faster
• GCM: 2-9% faster

However, making the change would make Encrypt() and Decrypt() each thread-unsafe i.e. encrypt and decrypt can run at the same time but no more than one go routine can run Encrypt(), and no more than one go routine can run Decrypt() simultaneously.

This is OK given usage here in pion/dtls (packets are processed sequentially per connection)... there is never more than one Encrypt() or Decrypt() on the same cipher object at the same time...

Unfortunately this package is public (/pkg/crypto/ciphersuite) and who knows how its being used outside of pion/dtls, it could be being used as a generic crypto primitive outside of the context of dtls e.g.

gcm, _ := ciphersuite.NewGCM(key, iv, key, iv)

go encryptFile(gcm, "file1.txt")
go encryptFile(gcm, "file2.txt")
go encryptFile(gcm, "file3.txt")

...So it would be unwise to go from thread-safe to thread-unsafe without a major release. I will remember to make that change right before the next major release.

See #795 related to my comment above.