This is a discussion on Re: Patch: save/load state of SHA1 - Openssl ; Nanno Langstraat wrote: > The intended use of the patch is to call SHA1_Load_State() directly, not > SHA1_Init() followed by SHA1_Load_State(). > > In other words: > > * The application starts by freely choosing either SHA1_Init() or > SHA1_Load_State() ...
Nanno Langstraat wrote:
> The intended use of the patch is to call SHA1_Load_State() directly, not
> SHA1_Init() followed by SHA1_Load_State().
> In other words:
> * The application starts by freely choosing either SHA1_Init() or
> * The application ends by freely choosing either SHA1_Final() or
This makes the API lifecycle distinct, either you are using the SHA_CTX
for Init/Final or Load_State/Drop you cant mix, is there a technical
reason why this is so? Like I pointed out you used to be able to
memcpy() the SHA_CTX with OpenSSL before the concept of an 'engine' was
From the points above I now understand that your intention is for
SHA1_Load_State() to be allowed to be called on an uninitialized
SHA_CTX. Which voids my point on SHA1_Init_FromState() and thats fine.
SHA1_Drop() still seems like a bad naming choice to me and is not
self-documenting. Maybe these sorts of voodoo issues can be cleared up
with good documentation in the man-page. Maybe SHA1_End() is a better
than than SHA1_Drop(). init/end create/destroy load/save pickup/drop
have clear self documenting meaning.
>> 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)
>> 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'.
> I beg to differ.
> Leaving this up to the application is another way of saying that
> inter-operability will happen not at all or badly.
> In particular, the patch currently handles endianness and word size,
> which the application inherently can not, because the saved state will
> always be an opaque binary blob as far as the users are concerned. They
> don't know anything about the internal format of SHA1, nor should they.
How do you know its compatible for all CPU architectures and all
possible engines ? I think you are over stating the compatibility your
scheme implies. It is for all intents and purpose opaque data that only
means something when presented to the correct implementation of the
digest that created it.
If you want inter-operability because your applications needs that
guarantee then I think you are going to have to pin the implementation
OpenSSL chooses to use (from all the available engines a given
implementation may have available to it) or use a 3rd party
implementation (or manually copy the OpenSSL source C implementation
into your own revision control so its static in your product).
> With regard to the SHA1_State_Version() call: it is a good addition in
> the sense of 'SHA1_State_Default_Version()'.
> But it does not really replace the 'requested_version' parameter of
> SHA1_Save_State() in the current patch: if a distributed process linked
> to a future newer version of OpenSSL needs to inter-operate with a
> process on another machine linked to an older version of OpenSSL, the
> current patch allows the first process to request an older version of
> the SHA1 state blob format so that the older OpenSSL will be able to
> Load() it.
The working state of the SHA_CTX is implementation dependent, sure there
is a common documented algorithm but there is no garuntee the internal
state has to remain the same. One possible example maybe a silcon based
SHA1 engine which would keep state and support the loading/saving of state.
Partly for the reason that a silcon based SHA1 engine maybe in use or
may not be in use for a particular SHA_CTX is a reason (I did not make
clear before) that the "u_int32_t SHA_State_Version(SHA_CTX *);" would
be the prototype. As it depends on how the SHA_CTX was inited on the
system in question as to which implementation of SHA was used and
therefore what opaque internal data you can load/save.
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com