"Wan-Teh Chang" <[EMAIL PROTECTED]> writes:
>Some of the security holes resulting from improper
>application of cryptography are very subtle and were
>not obvious to even experts before they were discovered.
>This is why Gutmann and my colleague Nelson urge people
>to use high-level cryto API or security protocols.
>They are not treating crypto library users as idiots.
>They are not saying that you don't need to use good
>software engineering practices to eliminate other
>kinds of software security holes (such as buffer
>overflows).
Exactly. The majority of the people using these libraries are general
programmers and not cryptographers. The point of the Lessons Learned paper
was that they shouldn't have to be cryptographers to be able to use a crypto
library. It's the job of the cryptographers who create the library to take
care of the crypto side of things, and leave the general programming to the
users (users in this case being users of the library, not end users).
Since these users are not cryptographers, the best interface for them is at
the highest possible level, "sign this message" or "secure this network link".
If the users are required to spend days or weeks learning crypto theory just
to get a signed message from A to B, then the creators of the library haven't
done their job properly [0].
(In practice of course the users won't spend days or weeks learning crypto
theory, but will just use whatever seems to work. Typically, the security of
the approach used will be, uhh, not so good).
Peter.
[0] Obviously there are exceptions to this, for example if you're doing
embedded systems crypto then you can't really provide the luxury of a
createPGPMessage() API when you're running in 32KB of RAM. libtomcrypt
(which I mentioned in a previous message) is an example of this, it's
targeted at low resource requirements rather than a does-everything
high-level interface.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
