Early std.crypto

[Piotr Szturmaj]

Martin Nowak wrote:
> I have to say though that I like the current struct based interface
> much better.
>
> struct Hash
> {
> // enhanced by some compile time traits
> enum hashLength = 16;
> enum blockLength = 0;

The reason why hash and block length are runtime variables is that some 
hash functions are parametrized with variables of great amplitude, for 
example CubeHash may have any number of rounds, and any size of block 
and hash output.

> // three interface functions
> void start();
> void update(const(ubyte)[] data);
> void finish(ref ubyte[hashLength] digest);
> }

There, it is:

reset();
put();
finish();

The put() function makes hash implementation an OutputRange.

> You wouldn't need the save, restore functions.

They're not needed. They only serve as speed optimization when hashing 
many messages which have the same beginning block. This is used in HMAC, 
which is:

HMAC(func, key, message) = func(key ^ opad, func(key ^ ipad, message));

when func supports saving the IV, the first parts are precomputed, when 
not HMAC resorts to full hashing. This optimization is also mentioned in 
HMAC spec.

> Some unnecessary allocations could go away.
> Most important instances would have less mutable state.

Could you specify which ones, please?

> You could probably parameterize a Merkle Damgård base with free
> functions for the transformation.

What would be the difference from current class parametrization?

> A dynamic interface can be obtaines by templated instances similar to
> what std.range does.

Could you elaborate? I don't know exactly what do you mean. Function 
templates?

Thanks a lot!