crypto/cipher: NewCTR is too expensive for small runs #39365
Comments
ianlancetaylor
changed the title
|
CC @FiloSottile |
ianlancetaylor
added
the
NeedsInvestigation
|
The AES-IGE mode is used in telegram: cipher, err := aes.NewCipher(key[:]) // allocation
if err != nil {
return nil, err
}
plaintext := make([]byte, len(data))
d := ige.NewIGEDecrypter(cipher, iv[:])
d.CryptBlocks(plaintext, data)Telegram uses different iv and key for each message. Should I create another issue for this? |
|
@FiloSottile Any chance you could consider this, now that the tree is open again? |
|
I think, that CTR mode is slow on small runs, because it precalculates 512 bytes: Can the size of precalculated buffer be set to BlockSize? Method |
|
I made an experiment: reduced diff --git a/src/crypto/cipher/ctr.go b/src/crypto/cipher/ctr.go
index eac8e266cf..9b93f43c69 100644
--- a/src/crypto/cipher/ctr.go
+++ b/src/crypto/cipher/ctr.go
@@ -25,7 +25,7 @@ type ctr struct {
outUsed int
}
-const streamBufferSize = 512
+const streamBufferSize = 32
// ctrAble is an interface implemented by ciphers that have a specific optimized
// implementation of CTR, like crypto/aes. NewCTR will check for this interfaceComparison of benckmarks: |
Hi,
SRTP, the security mechanism used by WebRTC, encrypts each packet individually with a different IV. Current implementations use AES in CTR mode, with the IV derived from the packet sequence number, the track's identifier (SSRC), and the phase of the moon. The Pion WebRTC library implements this by calling
cipher.NewCTRfor each packet. This turns out to be one of he main sources of memory allocations in the library.Pull request pion/srtp#76 works around the problem by implementing a function that performs the equivalent of
cipher.NewCTRfollowed byXORKeyStreamwithout allocating the Stream structure. However, the Pion maintainers appear to believe that the client library is not the right place to perform this kind of manipulation.I humbly suggest that the library should include a function
which performs the equivalent of
NewCTRfollowed byXORKeyStream. An alternative would be to add a functionwhich resets a
Streamto its initial state without reallocating the buffer. Of course, due to backwards compatibility, this would not be added to the existingStreaminterface, the client would need to check for it explicitly.The text was updated successfully, but these errors were encountered: