Re: Choosing an implementation language
== Eric Rescorla [EMAIL PROTECTED] writes: Tyler Close [EMAIL PROTECTED] writes: On Thursday 02 October 2003 09:21, Jill Ramonsky wrote: I was thinking of doing a C++ implentation with classes and templates and stuff. (By contrast OpenSSL is a C implementation). Anyone got any thoughts on that? Given the nature of recent, and past, bugs discovered in the OpenSSL implementation, it makes more sense to implement in a memory-safe language, such as python, java or squeak. Using a VM hosted language will limit the pool of possible users, but might create a more loyal user base. There's already a Java SSL with a simple API: http://www.rtfm.com/puretls/ There is also a standardized and widely distributed implementation and API. JSSE is bundled with J2SE as of v 1.4: http://java.sun.com/products/jsse/ -- mailto:[EMAIL PROTECTED] Knowledge speaks, but wisdom listens. -- Jimi Hendrix - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Choosing an implementation language
Ah, the joys of diversity. Implementations of all your favorite protocols in all your favorite programming languages by all your favorite programmers in all your favorite countries on all your favorite operating systems for all your favorite chips. Continuous debugging certainly is the path to secure computing. Cheers, Scott -Original Message- From: Tyler Close [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 4:31 PM To: [EMAIL PROTECTED] Subject: Choosing an implementation language On Thursday 02 October 2003 09:21, Jill Ramonsky wrote: I was thinking of doing a C++ implentation with classes and templates and stuff. (By contrast OpenSSL is a C implementation). Anyone got any thoughts on that? Given the nature of recent, and past, bugs discovered in the OpenSSL implementation, it makes more sense to implement in a memory-safe language, such as python, java or squeak. Using a VM hosted language will limit the pool of possible users, but might create a more loyal user base. I know the squeak community http://www.squeak.org/ does not have SSL and would very much like to have it. An implementation of SSL in squeak would also be of interest to the Squeak-E project, related to the E project http://www.erights.org/. Tyler -- The union of REST and capability-based security: http://www.waterken.com/dev/Web/ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Choosing an implementation language
On Fri, Oct 03, 2003 at 04:31:26PM -0400, Tyler Close wrote: On Thursday 02 October 2003 09:21, Jill Ramonsky wrote: I was thinking of doing a C++ implentation with classes and templates and stuff. (By contrast OpenSSL is a C implementation). Anyone got any thoughts on that? Given the nature of recent, and past, bugs discovered in the OpenSSL implementation, it makes more sense to implement in a memory-safe language, such as python, java or squeak. Using a VM I strongly disagree. While an implementation in a typesafe language would be nice, such implementations are already available -- one's packaged with Java, for instance. From my point of view, the starting point of this discussion could be restated as The world needs a simple, portable SSL/TLS implementation that's not OpenSSL, because the size and complexity of OpenSSL has been responsible for slowing the pace of SSL/TLS deployment and for a large number of security holes. For practical purposes, if such an implementation is to be useful to the majority of the people who would use it to build products in the real world, it needs to be in C or _possibly_ C++; those are the only languages for which compilers *and* runtime environments exist essentially everywhere. Coming from a background building routers and things like routers, I can also tell you that if you're going to require carrying a C++ runtime around, a lot of people building embedded devices will simply not give you the time of day. An implementation in a safe language would be _nice_, but religion aside (please!) it's a cold hard fact that very few products that people actually use are written in such languages -- if you leave Java (which already has an SSL implementation) out, very few becomes essentially zero. And if we're interested in improving the security of not only our pet projects, but of the interconnected world in general, it seems to me that producing a good, simple, comprehensible, small implementation *and getting it into as many products as possible* would be one of the better possible goals to work towards. Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
