[Mono-dev] Question about TransformFinalBlock with SymmetricAlgorithms and CBC
davidiw at ufl.edu
Fri Jan 30 16:02:46 EST 2009
Sebastien Pouliot wrote:
>> Thanks for the wealth of information and making it clear. I agree this
>> is not the issue, obviously we cannot use the TransformFinalBlock
>> without a) creating decryptors and encryptors each time or b) force
>> users to use a frozen mono version. So back to the original question...
>> "We're currently using this on a datagram security system and on Mono
>> (not sure if .Net is the same) creation of Encryptors and Decryptors is
>> expensive. Any thoughts or suggestions?"
> First make sure if this is the creation of transforms that is costly
> (something that you could save by resetting the transform) or if it is
> the cipher initialization (that you can't save anyway by resetting the
> transform). It's likely a bit of both... but that will tell you what
> options is best.
>> Could we yank out the guts of Mono's FinalEncrypt/FinalDecrypt and just
>> use the TransformBlock instead of the internal calls without worries?
> Yes you can. All the code is available, MIT licensed. The existing API
> has limitations (it's not very memory friendly) so you could adapt the
> code to use an API without any memory allocations (beside the initial
> buffers) which could help performance - at least if this fits your
>> Is there another approach that I am blind to?
> You could also use machine.config support to use a native implementation
> of AES (I assume this is the Rijndael mode you're using anyway).
> You'll find hand-optimized assembly implementation of most existing CPU.
> In this case you'll need to write a C# wrapper around it and ensure it's
> registered in machine.config (if you want to replace the default).
> Alternatively you could have your C# code do a fallback to the existing
> managed code if the native library is unavailable (and show a warning to
> the end-users).
Thank you for your excellent feedback.
More information about the Mono-devel-list