Jill Ramonsky wrote: > Example. You're a company. You build hardware devices which need to talk > to each other securely. (Say, ATMs for example). Obviously it wouldn't > make sense for that company to have to supply its ATM-using-customers > with the source code of the ATMs.
Who's the customer, the one that buys and deploys the ATMs, or the actual customer who interacts with it? I can only recommend to demand source code before purchase/deployment, especially for embedded devices which are supposed to communicate securely over an untrusted network. Custom crypto protocols appear to be quite common in this area. Even if you lack the necessary time and experience to detect subtle flaws in the implementation, it's likely that you'll discover a few surprises. Did you know that proprietary Blowfish libraries exist which are extremely easy to use? They even provide a default key which is used unless another key is imported explicitly. This neatly solves all key management problems. (The key, by the way, is the third one you would check if you had to guess it.) > This is an important question (for me, at least) since it affects the > licensing of the yet-to-be-written TLS++ project. There are few licenses today which require distribution of source code to end users if they don't receive binaries. One prominent exception is the Afferro (sp?) GPL. > 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". If you want to see widespread adoption of your Better TLS Library, you should avoid such licensing experiments. Use a BSD or MIT-style license instead. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]