Open Source (was Simple SSL/TLS - Some Questions)

Jerrold Leichter jerrold.leichter at smarts.com
Tue Oct 7 13:12:32 EDT 2003


| Maybe the solution should be this: You can distribute the binary without
| any source code whatsoever, and use this toolkit, unrestricted, in
| whatever manner you choose, provided that EITHER you distribute the
| source code for the whole product in a form which allows the user to
| reconstruct a working executable from the source code, OR you include a
| message which says something like "Warning - this product is closed
| source. If you rely on its crypto features, you do so at your own risk".
No commercial software is ever going to use your software based on those
requirements.  Oh, sure, the software vendors all write language into their
contracts that try to dump all the risk on the buyer - and the current
attempts at a class action suit against Microsoft may determine the degree to
which the courts let them get away with it.  But no one is going to let you
impose *your* language on the way they talk to their customers - unless you
make your requirement so mealy-mouthed that it's pointless, or you allow them
to hide the language so deep that no one ever sees it.

At some point, you need to decide whether you are doing this in service to
some kind of idealism about perfect cryptography for the masses, or whether
you want to improve the state of the world by making it easier for honest
vendors to easily provided good crypto.

I'll let my bias show:  If the vendor of your software wishes to attack you,
there's not a hell of a lot you can do about it.  It's just too hard to hide
things, if you set your mind to it.  Even accidental bugs take huge effort to
find - whether you believe that "all bugs are shallow to sufficiently many
eyes" or not, there's no bug-free open-source software out there any more than
there's bug-free closed-source (...which may simply mean that there aren't
sufficiently many eyes - but there likely never will be.)  *Deliberate* bugs
in a system of significant size?  I can't even imagine the effort necessary to
gain assurance that there aren't any, given the current state of the art.
(Sure, in an eventual world with multiple independent proved-secure compilers
and libraries for safe languages, verifiers, proof-carrying code or some such
technique ... maybe.  But the necessary infrastructure is currently way beyond
the state of the art for all but very specialized, limited domains.)

							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list