hkdf: automatically switch between Hmac and SimpleHmac

[newpavlov]

With this change the implementation automatically selects Hmac for "eager" hashes and SimpleHmac for "lazy" ones.

The main disadvantage of this approach is that new Hkdf will work only for hash functions defined using CoreWrapper. Ideally, we would use specialization here, but we probably can work around this by tweaking digest and hmac. We need to distinguish between eager hashes which can return hash "core" and other hashes. Plus, it should be done in a way which allows compiler to see that implementations in this crate do not overlap.

[tarcieri]

Seems like this would preclude switching to newtypes of CoreWrapper for the hash crates.

Could this blanket impl be based around the requisite traits instead?

[newpavlov]

I don't think it's possible to do automatically without specialization. Alternatively, we could introduce yet another trait which would regulate switching between those two HMAC implementations, i.e. we would move this burden to all hash implementation crates.

[tarcieri]

Then I would personally rather have newtypes than this automatic switching.

Have you benchmarked how much SimpleHmac actually degrades performance for the short inputs in HKDF usage?

[newpavlov]

We already have the SimpleHkdf type aliases, which do the job just fine.

It's more about structure size, depending on hash, SimpleHmac can be twice bigger, especially if the reset feature is enabled for hmac.