On Fri, Oct 03, 2003 at 05:55:25PM +0100, Jill Ramonsky wrote: > Having been greatly encouraged by people on this list to go ahead with a > new SSL implementation,
That's a pretty good idea, I also encourage you (and volunteer to support). > The main > point of confusion/contention right now seem to be (1) should it be in C > or C++?, I definitely vote for C++ for several reasons. You already mentioned plenty of reasons yourself, the security advantages of C++. But be warned: In contrast to modern scripting languages C++ is not automatically immune against buffer overruns etc. It takes some discipline to have a good programming style in C++. The main advantage I see is the oportunity to have a good, object oriented design of the API to give an example of a good and usable Crypto API. Everyone here has his own favourite language, I meanwhile prefer Ruby. I had to write a CA some months ago and didn't find a good language with SSL and Certificate management support, except for Ruby. Michal Rokos <[EMAIL PROTECTED]> was currently writing the glue code to use the openssl library with ruby, and I found it very comfortable to use SSL from a scripting language. It was however a big heap of debugging, reading the openssl API and source code, discussing requirements with Michal, ask him for extensions etc., since it is quite difficult, to implement all features of openssl, and many of them are not logical. This project showed the shortcomings of openssl, it is not really a usable and complete software. This causes insecurity, because it is too difficult for application writers to use it and to support all features. I'd therefore propose the following: To design two (ore more) object oriented APIs for - cryptographic primitives - non-communication oriented functions (key and certificate management, S/MIME message handling, ...) - communication oriented functions (SSL/TLS) but to not stick too tight to C++. The design must be applicable to all modern object oriented languages. Then do a C++ implementation of the API (spell: header files) and see, whether this is possible without tricks. Also have the API defined in other languages such as Python, Ruby, Java,... Take care that the design is easy to read, easy to understand, easy to debug. Make use of object oriented design where possible. Now implement the library itself in C++, while others write the glue code for other languages simultaneously. As a result, there will be a language-independend object-oriented Meta-API, describing the library virtually for all languages. For every supported language there is a "translated API" of this and a library to use. For C++, this is a genuine library, for other languages this will be glue code + the C++ library. This would be a step to bring secure programming a step forward towards modern programming, and to ease and support use of SSL/TLS/... I am currently quite happy with the way Michal Rokos wrapped openssl into an object oriented API, but it would be good to have this in more languages, it still allows improvements and is still incomplete. regards Hadmut --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]