Marsh Ray <[email protected]> writes: >> 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.
I've been following it since CryptoAPI 1.0, initially it was a fairly straightforward, basic API, but it's been bloated up over time on the design principle of of "gimme an API to do X" as required, so it evolved rather than being designed as such. For example CryptDeriveKey() is really CryptProcessPasswordForWindows() (or perhaps CryptLoadContextFromHash()) rather than something where you can do PBKDF2, PGP S2K, the TLS and SSH PRFs, and so on. In addition many of the lower-level functions in CryptoAPI are realy only useful for implementing higher-level bits of CryptoAPI, but not as a general-purpose API for crypto. So if your goal is "I want to do crypto the Windows way" then it's perfectly fine. If OTOH it's "I want to read certs from the Windows cert store for use in a non-CryptoAPI app" (for example) then you're in for quite a bit of pain. >OK, but when one of the buckets has 0 observations in it what is it proving >exactly? That no successful crypto API has ever been designed by a committee? We have (at least) CDSA, TCG, and GSS-API, and none of those have seen any significant adoption (by "significant" I mean at the same level as CryptoAPI, OpenSSL, etc). >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. See above. Note that the two lists were of "Successful crypto APIs", not "Any kind of crypto API". I'm not aware of any designed-by-committee crypto API that's had any real penetration in the marketplace. >Netscape/Mozilla's NSS might be another interesting data point. How much of that is PKCS #11 and how much is non-PKCS #11 NSS? But yeah, that'd be another example. >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. Actually I was surprised during the discussion of adding explicit IVs in TLS 1.1 that people brough up API issues to argue for or against particular designs. I'd never seen that in other WGs. >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 Does anyone or anything of any significance use that API? I looked at it when the RFC was published and, not to put too fine a point on it, it didn't seem to be based on any great implementation experience. >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. But almost anything (including recreational pharmaceuticals) can act to "improve the quality of the protocols and specification". Is bringing API considerations into the design process a suitable cost/benefit tradeoff? Could you achieve the same (or better) with a few beers worth of analysis? The biggest factor that would affect IETF protocol design in my opinion is a requirement to provide legitimate real-world (not gedanken-experiemtn) usage cases. That requirement alone would instantly halve (or more) the complexity of most security protocols (and, by extension, improve the quality etc etc). For my part I'd be absolutely terrified of the IETF trying to specify an API. The strength of IETF specs is that they're purely functional, so you can implement them in C, Java, PHP, or by waiting for single event upsets to flip the appropriate RAM bits, and as long as you get the same bits on the wire you're OK. OTOH if a WG ever gets asked to design an API it'll make Bosnia look like a cakewalk. Just the bikeshedding over which language bindings to use could take years if not decades. Then there's synchronous vs. asynchronous interfaces (the HW guys want async for performance, the software guys want sync because async is hard), how do we make things thread-safe (does the caller have to do it, or should we have abstract locking objects, or does the code library do it), should we make it more OO or more functional... this isn't just a bikeshed, it's a twelve-storey bikeshed with a magnificent entrance hall, carpeting throughout, 24-hour portage, and an enormous sign on the roof, saying "This Is a Large Bikeshed". See "CDSA" for an example. Peter. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
