On 06/22/2011 07:17 AM, Peter Gutmann wrote:
Crypto API designed by an individual or a single organisation:
CryptoAPI: A handful of guys at Microsoft
I always kind of thought this one looked like someone went a little wild
with the UML modeling tools.
PKCS #11: Someone at RSA (I've heard different stories).
One could do worse.
JCE: A couple of guys at Sun.
This one underwent breaking changes which, to this day, requires us to
maintain two sets of code where I work.
OpenSSL: Using the term "designed" very loosely :-), Eric Young and Tim Hudson.
I'll withhold comment on this one until the documentation is complete. :-)
And last but not least let us not forget http://botan.randombit.net/ by
our gracious email list host!
Crypto API designed by a committee:
QED, I think.
OK, but when one of the buckets has 0 observations in it what is it
proving exactly? Maybe simply that most crypto APIs in common use are
designed by a "handful" or fewer guys. Which probably counts for
something, but I think it's not so obviously prescriptive.
* Perhaps the effect you're seeing could be explained by a crypto API
being a relatively straightforward data-in data-out type of thing. Or at
least that's a workable oversimplification.
* It would say a lot more if there were some examples of
committee-designed crypto APIs that nobody wanted to use because of
those noticeable effects.
* Netscape/Mozilla's NSS might be another interesting data point.
WRT IETF involvement:
* A typical IETF spec doesn't seem to have any more authors or
significant contributors than a "small" engineering team at a big company.
* Having a concrete API can keep the design grounded. There are some
things in TLS that have *no* representation in any sane API. This could
only have occurred by the design leading the implementation a little too
far.
* There already are crypto APIs being defined in RFCs, they're just
ad-hoc and lacking interoperability. E.g.
http://tools.ietf.org/html/rfc6234#section-8.1
The purpose of the IETF considering APIs in general isn't *just* that
we'll all get some huge new API to use and which will be considered a
failure if the whole world doesn't move to it immediately. Just the
process of defining an API holds potential to improve the quality of the
protocols and specification.
The prior policy of IETF seemed to frown on formal consideration of
APIs. I think that should definitely change, although it's not really an
argument in support of this specific proposal.
- Marsh
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
