On Jun 21, 2011, at 6:50 AM, Peter Gutmann wrote:
"Novikov, Lev" <[email protected]> writes:
There is an existing class of devices and environments (e.g.,
military and
diplomatic communications) which have particular requirements that
are hard
to retrofit into existing crypto APIs (i.e. the logical models are
substantially different).
For example, many of these devices operate in a manner such that
the results
of cryptographic operations are not returned to program that
initiate the
operation--as they are in existing crypto APIs. Rather, the request
starts in
one security domain, is executed by the crypto (which is on the
border
between two domains), and the result emanates in another domain.
I guess my question had insufficient detail :-). The problem is that
introducing a totally new crypto API today is going to be pretty much
impossible. The NSA, in the mid to late 1990s, when the only well-
established
crypto API around was PKCS #11, published three different reports on
crypto
API design, presumably to meet the sorts of goals you're listing,
but AFAIK
the work never went anywhere. Now we have PKCS #11, CryptoAPI, JCE,
OpenSSL,
and some others, as well-established, entrenched APIs.
plus RFC 5116, an internet standard that defines a simple interface to
authenticated encryption with associated data, and is used by nine RFC
and is referenced by 14 current internet drafts.
David
http://www.mindspring.com/~dmcgrew/ic/aead2.html
ftp://ftp.ietf.org/iana/aead-parameters/aead-parameters.xml
I cannot imagine what size hammer you'd need to wield to convince
vendors to
implement a totally new API for their products. You might be able
to add a
new object-type to PKCS #11 (this has been done for some other
mechanisms like
additional auth.mechs) to handle this, leveraging the investment in
the
existing API, but I just can't imagine how you'd get vendors to
support a
completely new API (even for PKCS #11, development has pretty much
stagnated
for some time, not through any lack of interest but because you can
do pretty
much everything that most users need, so there's not much incentive
to push
things in new directions). The problem really is political, not
technical.
Peter.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
