[Mono-dev] [PATCH] Set hash algorithms block size

[Javier Martín]

Hi,

I had though of interleaving my replies with your message, but it soon
became inintelligible. So I will summarize my points here.

I checked the docs in MSDN before even trying to modify the sources.
The description is just "size of input data blocks in bytes". Sorry if
I have misinterpreted it as "preferred data size" instead of "valid
block size". If you take a loook at most implementations of the many
hash algorithms I had submitted for modification, you'll see that, for
example, MD5 can't process data chunks of arbitrary lengths, but just
BLOCK_SIZE multiples (64 bytes iirc?). It gives the illusion that it
can because it buffers data. However, it is able to buffer because its
"output data" (in the sense of the output array in TransformBlock) is
discarded. AES, on the other hand, can _only_ parse BLOCK_SIZE
multiples because it _must_ give an output block for each input block.

The _real_ problem here is that different classes (CryptoStream and
MD5/SHA1/etc.) are trying to do buffering and passing the data between
themselves in 1-byte arrays, and none offers you an option to disable
this. In my profiling, CryptoStream and TransformBlock called
Buffer.BlockCopy once per each byte in the file (!!). 63 out of 64
calls, MD5 just buffered the data and returned (which could had been
127 out of 128 for SHA384), with some major overwhead in continuous
callvirt, newarr, etc.

By the way, hashing data as it passes through a CryptoStream is (in
MS, should be in Mono) a quite efficient method, especially if you
have many hash algorithms or some other crypto transforms.

Summarizing, the most important thing here is (sadly but reasonably)
compliance with the MS standard API, so I agree that the [IO]BlockSize
properties should return 1 even when the logical value would be
BLOCK_SIZE. This makes fixing CryptoStream even more important (and
this time, yes, I have checked MS does not have that bug).

Thus, -- I REQUEST MY PATCH TO BE DISCARDED --

PD: and so I'll work on that CryptoStream.Read bug ^^