I have an application that pre-initialises a HMAC with some computed
data, then at high throughput it is copied for different requests into
a unique context and used from there.
The main reasons were to save calling HMAC_Init() and HMAC_update() with
the same data before I could start a verify. Also a side effect that
it maybe more secure than storing the exact key in the process address space,
since there is no need for it anymore if I prime a HMAC context and the
data within the HMAC is marginally safer.
Sometime ago I did evaluate the HMAC context structure in OpenSSL and a
public domain MD5 impl and concluded it was just storage (i.e. it has no
pointers to allocated storage that needed to be duplicated) so I was
using a simple:
memcpy(&hmac_context_this_packet, &hmac_const_global_initilized, sizeof(foo));
but this is a big assumption I don't really want to make.
I was thinking it would make sense to add this to the API, to be able to
initialize one HMAC structure from another so that both have their own
lifecycles, rather than presuming I can memcpy() it.
Does this make any sense to add this into the HMAC APIs, even if thats
still a memcpy() inside OpenSSL this then obligates OpenSSL to provide
that in the future. Would a patch be accepted ?
--
Darryl L. Miles
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
