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> Envoyé : 2 octobre 2019 23:31 À : Benoit Laforest <benoit.lafor...@ubisoft.com> Cc : 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
