Hi, I did some tests and I realised that the current implementation does not support reusing the same GcmBlockCipher with different IV.
I will try to make a slight modification in the GcmBlockCipher to avoid reallocating memory internally while still allowing a less costly re-initialisation with a new IV. Since we need to encrypt at a 60 fps rate, we need to avoid perpetual reallocation. Is there a reason why it was decided NOT to support reusing the same gcm block cypher, even wih a different IV each time? Has it anything to do with protection against attacks implying some memory analysis? About the tests, I still tried to encrypt a 1500 bytes at a 60fps rate, by recreating a new GcmBlockCypher each time and in the end, it took about 26-30 ms for 60 iterations, with a debug version of the DLL. This is less worse than expected. I will to more testing with the release version and also with the modified gcm cypher block to save time on initialization. Benoit De : Benoit Laforest <benoit.lafor...@ubisoft.com> Envoyé : 2 octobre 2019 23:40 À : Sid Shetye <sid...@outlook.com> Cc : dev-crypto-csharp@bouncycastle.org Objet : RE: [dev-crypto-csharp] About memory usage with the GcmBlockCipher Thanks for the advice and info Sid, I will continue my test to see what can be done. From the numbers I mentioned before, this would mean to require around 78kb/sec of bandwith. Regards, Benoit De : Sid Shetye <sid...@outlook.com<mailto:sid...@outlook.com>> Envoyé : 2 octobre 2019 23:31 À : Benoit Laforest <benoit.lafor...@ubisoft.com<mailto:benoit.lafor...@ubisoft.com>> Cc : dev-crypto-csharp@bouncycastle.org<mailto:dev-crypto-csharp@bouncycastle.org> Objet : Re: [dev-crypto-csharp] About memory usage with the GcmBlockCipher Not directly answering your question, but I think you might want to test reusing the GCM params to see if even with a broke approach you can hit 60fps. I don’t think Bouncy castle uses AES-NI intrinsics yet, which may limit your ability to hit 60 fps regardless of the aead param issue. Actually, does anyone know what (if any) are the plans for using AES NI on PC processors? The latency and throughout difference software-only vs AES-NI accelerated is massive (kinda like GPU vs software rendering). On Oct 2, 2019, at 8:13 PM, Benoit Laforest <benoit.lafor...@ubisoft.com<mailto:benoit.lafor...@ubisoft.com>> wrote: Hi, We want to use the GcmBlockCipher with 256 bit AES key (created from X25519 DH agreement) to encrypt our gameplay payload at 60 frame/sec before sending it (at the same frame rate). The payload data size may vary between 800 to 1300 bytes, this is not final yet. Our main concern now is there seem to be way for the moment to reuse a AeadParameters without reinstancing it, which will lead to a lot of garbage collect, that we cannot afford for our network game. The ideal way would have been to reuse the same GcmBlockCypher and parameters and simply change the IV every frame before each encryption, and then send the encrypted payload with the IV. Has someone encountered the same type of challenge before? Or maybe we misunderstood something? Thanks a lot, 😊 Benoit
