Darryl Miles wrote:
Nanno Langstraat wrote:
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.
Leaving this up to the application is another way of saying that
inter-operability will happen not at all or badly.
How do you know its compatible for all CPU architectures
We use htonl(). Restricting ourselves to C implementations for this
paragraph, is there a credible situation where that is not sufficient?
and all possible engines ?
No, certainly, a hardware engine that does not have a fully documented
format of its internal state will never be made state-compatible with
any other engine.
But in the worst case, either EVP_Digest_Load_State() or the user can
fall back on the C implementation, right? See also below.
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
In the vast majority of cases the user will be able to get a combination
that works. Usually automatically, if necessary manually by setting
'requested_version' and the engine.
Future versions of the C implementation with a wildly different internal
state can contain conversion code to work with old state data versions
if there is a user demand for it.
The one thing that we really can not handle ever is to receive state
saved by an undocumented hardware engine from the user, and load it into
another engine.
Even that can be prevented from ever happening, if we want to. E.g. by
urging the user to use something like a newly added EVP_DigestInit_ex2()
with a flag "select an engine that will produce documented state that
we'll be able to load into other engines".
--
Summarizing, OpenSSL can manage this problem for the vast majority of
cases, tending towards "all cases". Why then would we burden each of our
users with it?
(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).
Using a static private SHA implementation was considered by us before
embarking on this OpenSSL patch, but that is just admitting defeat. It's
avoiding the problem instead of fixing it for other people who'll
encounter the same situation as us.
Regards,
Nanno
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
