This is a discussion on Re: Patch: save/load state of SHA1 - Openssl ; This seems like a good time to air my thoughts. OpenSSL used to have digest algorithms which the state could be saved (with a simple memcpy), but then introduced 'engine' based generic methods. I really would like to see OpenSSL ...
This seems like a good time to air my thoughts. OpenSSL used to have
digest algorithms which the state could be saved (with a simple memcpy),
but then introduced 'engine' based generic methods.
I really would like to see OpenSSL support BOTH usage. That is have a
generic API which can support "engine's" and must follow the calling
convention necessary for that to happen with clear object encapsulation,
but also provide the original method of working that has a more
strightforward usage and did allow for saving of state via a memcpy.
Your suggestion of a formal save state and load state functions are nice
and I'd like to see them in the implementation as well such that in the
case of non-engine usage end up being the traditional memcpy().
I think SHA1_Load_State() should implicitly take care of the free() /
release() like operations necessary to reload state.
SHA1_Drop() seems like a bad name to me, maybe a better name would be
SHA1_Clear() or SHA1_Reset() if the intention is to cause the internal
state of the SHA1 to reset back to SHA1_Init() but it MUST be used on an
already initialized SHA1 object.
This leaves open the obvious API usage of wanting to jump start
SHA1_Init() and SHA1_Load_State() if this is needed then consider
creating a SHA1_Init_FromState() for this purpose (SHA1_Init_State()
feels too vague and potentially misunderstood).
I'm not sure if your method of versioning the state information is
sufficient, I would like to propose that this problem domain be left
mainly upto the application to deal with. My concern stems from
different machine types, endianess and natural bitwidth (32/64bit) issues.
If OpenSSL is to provide some form of API contract for the
representation of "State" to the application that a new function method
be used "u_int32_t SHA1_State_Version(void);". This would also be
combined with CPU type + endian information as appropiate.
It would be upto the application to store, know and check the 'State
Version' that it is using is compatible with the runtime version of
OpenSSL that is in use. rather than set a policy on how this 'State
Version' information is stored along with the 'State Data'.
SHA1_XXXX_State() function should simply deal with 'State Data'.
This is my pennies worth not that it counts for anything.
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com