Am 11.09.2012 20:21, schrieb Timo Sirainen:

On 11.9.2012, at 21.07, Florian Zeitz wrote:

...

...

I think we could simply #define the largest allowed context_size, use it for these buffers' sizes and then add i_assert(meth->context_size <= HMAC_MAX_CONTEXT_SIZE)

Well, either that, or we could use a union of all known context structs there.

That annoyingly requires #including in hmac.h all the different .h files that contain hash contexts. When new hashes are added I doubt anyone remembers to update that. And since the hmac_context is rather rarely used I don't think it matters if we just use a somewhat large context size.

...

Or we could use i_malloc() and i_free() under the assumption hmac_init()

• hmac_final() calls are always matched.

Yeah, that's not too bad either I guess. Although it is different from other hash_init()+final calls which don't require it, and it's also wasting CPU a bit.

Here is an updated version of the patch. It uses the variant defining the largest allowed content size. I choose 1024 bit (128 Byte), since that is what most of the SHA-3 candidates use, so it's hopefully somewhat future proof.

It's also rebased to the current head and switches the hmac uses added since the last version over to the changed API. It also fixes an "interesting" compiler warning I got with clang, which complained about the fact that struct hmac_context* was (re)declared in the prototype of hmac_md5_get_cram_context() and therefore separate from the one declared in hmac.h.

Regards, Florian