Hi. This is just a quick note to say that over the weekend I've done a lot of thinking about coding, and even some /actual/ coding, that I've re-read parts of Eric's book in somewhat more detail than I read it last time, and I've read all the various posts on the subject of "simple SSL". And at the end of all this study, I have finally decided exactly what I want/propose to do . I guess the point of this email is to tell you the plan, and to explain the reasons for my choices. There are also four more questions at the end, so if you can't be bothered to read this long email, please do skip to the end and consider the questions.
First, the primary design goal is "simple to use". This is not the same thing as "doesn't do much". As an implementer, I can make the toolkit as powerful as I want (and it will be open source, after a time, so others will be able to add to it and make it more powerful still). Adding power only makes the implementation harder to /write/. However, if well designed, it should not make it harder to /use/. Harder to write is my problem ... but I like a challenge!
Second design goal is "lightweight". This means that it must be possible for application programmers to use the toolkit to build minimalist applications. This means that part of the toolkit must be a statically-linked library consisting of many very small object modules, making it possible to link in only what you need, and no more. That said, if the toolkit is powerful, one could also use it to build "heavyweight" applications also. I don't see that as a problem, or even as a violation of the design goal. In fact, it actually seems to me to be something of an advantage that you could do both.
First design choice: SSL or TLS or both? I think this is covered by the paragraph above. If the toolkit lets you create TLS-only products, a lot of people will be happy (including me). If the toolkit /also/ lets you build SSL+TLS applications then a lot of /other/ people will be happy. Seems to me that so long as I am clear about the distinction between "what's in the toolkit" and "what's in a application /built/ with the toolkit" then a lot of design choice problems just disappear. (Or at least, become the application designer's problem).
Second design choice: C or C++ or something else? There was a lot of support on this list for both C and C++, and various "something else"s were also suggested, but with less votes. Many people suggested /both/ C and C++. Some said "write in C and then do a C++ wrapper". Others said "write in C++ and then do a C wrapper". The "embedded market" got several mentions, and for these guys it's clearly desirable to have a C version. Other factors to consider are my own expertise (I've never written anything in Ruby or Python before, so this would not be a good project to use as first attempt) and my own enjoyment. This is selfish, yes, but someone said this would end up being a year-long project, so I'd like it to end up firing my enthusiasm and imagination. More gets done that way, and faster. So here's the decision - the prototype will be in C++ ... /but/ ... I do know enough about how C++ compilers work behind the scenes, and I'm confident that I will be able to later port it to C, even /with/ features such as abstract virtual base classes, templates, exception handling, RTTI and so on. So what we'll end up with is both a C++ version and a C version, with the C++ version coming first. [It may even be possible to shortcut the port, for example by finding a C++ to C compiler, or by releasing an OS-specific binary with C wrappers]. And it seems to me that another big plus in doing a C++ version is that one does not already exist, and perhaps one should. Another big pro in favor of C++ is the existence of the crypto++ project (thanks for pointing that out to me, guys). This provides a lot of crypto primatives, which a TLS toolkit could put to good use.
Some people said that it was easier to code in C than in C++. I don't think that's true. I've been coding in C since it was invented. Likewise, I've been coding in C++ since /that/ was invented. In my opinion, bugs are easier to find and fix in C++ than they are in C, with most of the serious ones being detectable at compile time in C++, but only at run time in C. With that in mind, I believe I could do a safer implementation in C++ than I could in C. I also consider the fact that the reason C++ was invented was to help manage complexity, and let's face it, this project does involve complexity. Keeping it all object-oriented gives me nice little isolated, easily debuggable objects.
It was pointed out that C++ (as opposed to Java, etc.) does allow pointers, and hence does allow memory errors such as buffer overruns. That's true, but I tend to encapsulate my raw C++ pointers inside smart pointer objects which don't allow such errors. (These are already part of my existing codebase. They'll go open-source along with the rest of it). I believe I can minimise this danger.
Eric raised some points which I should address. First, he asked me "You have read the RFC, right?". Well I guess I should be honest here and say no, I hadn't done that yet. Maybe that's where I went wrong, and would have asked fewer dumb questions if I had. But rest assured everyone, I will digest it thoroughly before trying to implement it! He also asked "I'm trying to figure out why you care about this. The defined algorithms are good enough for almost all purposes.", and "Don't you want to be able to communicate with standard TLS implementations? If so, the kind of stuff you seem to want to do will in often break that.". To answer the first question, I have to state my absolute and sincere belief that if Alice, Bob, Carol, Dave, etc.., wish to communicate with each other privately, then it their business AND NO-ONE ELSE'S what choice of algorithm(s) they use, etc.. This leads inevitably to the conclusion that if a standards body forbids this, then the standards body will have to be circumvented. This of course leads to the second question, ("Don't you want to be able to communicate with standard TLS implementations?"). The answer is obvious. /Of course/ one should be able to communicate with standard TLS implementations, otherwise the toolkit would be worthless. And of course, communicating with other implementations /does /mean strictly obeying all the standards. These two positions are not, however, mutally exclusive, because what I am putting together is a /toolkit/, not an /application/. Application programmers will be able to use the toolkit to build standards-compliant applications if they want that, or anarchistic applications if they want that. (Of course, anarchistic applications will not interoperate with the rest of the world, but that's the price you pay for choosing that option, and it's what I mean by the phrase "private use by mutually consenting parties").
And now ... SOME MORE QUESTIONS. (You're gonna love this).
(1) THE LICENCE
I confess ignorance in matters concerning licensing. The basic rules which I want, and which I believe are appropriate are:
(i) Anyone can use it, royalty free. Even commercial applications.
(ii) Anyone can get the source code, and should be able to compile it to executable from this.
(iii) Copyright notices must be distributed along with the toolkit.
(iv) Anyone can modify the code (this is important for fixing bugs and adding new features) and redistribute the modified version. (Not sure what happens to the copyright notices if this happens though).
(2) THE NAME
Everything needs a name. I've come up with a few possibilities. I'd bet good money that people here could come up with a few more. Some suggestions are:
TLS++ (I like this one)
SimpleTLS (obvious, but not too bad)
EasyTLS (actually I'm not too keen on this - it sounds /too/ simple to be credible)
GnuTLS (obviously only suitable if it ends up with a Gnu license)
Pretty Good TLS (I stole the idea from PGP obviously, but if this is to be "SSL for the masses" then it's not entirely inappropriate)
...
Anyway, all suggestions welcome.
(3) MULTIPLY SIGNED CERTIFICATES
A technical question now. (I did look at RFC2246 before asking this, but didn't find the answer there). In GPG / PGP, one can have multiply signed certificates. It's not called a "certificate" in GPG, it's called a signed key, but the priniciple is the same. Alice can get her key signed by both Carol and Dave, which has the intended meaning that both Carol and Dave vouch for the authenticity of Alice's key. Thus, if Bob wishes to send to Alice, he can do so provided he trusts /either/ Carol /or/ Dave.
Can you do this with X.509 certificates? I know it would be hideously unusual (not to mention expensive) to get a single certificate signed by both Verisign and Thwarte, but can it be done? Is it possible? Is it allowed?
(4) MULTI-THREADING
Procedural languages like C tend to go for state-machine-like architectures. Object oriented languages like Java tend to go for multithreading. Both are conceptually solutions to the same problem, but arise from different paradigms. C++, being somewhere in the middle, hasn't really made up its mind which way to go. Multithreading is not built into C++ any more than it is built into C, but the OS usually provides multithreading anyway, so in object-oriented C++ you'd tend to go for multithreading (which, I have to say, is /considerably/ easier to understand and debug than the state-machine paradigm). My question is, how much of a problem is this for the embedded market?
I happen to know that it's pretty easy to put *cooperative* multithreading into an embedded application, providing you're willing to write a bit of assembler. (I've done it myself). But *pre-emptive* multithreading is much harder to implement (and more likely to incur synchronisation bugs). I can certainly write multithreaded routines which don't rely on pre-empting, so that should make it easy, but obviously I'm not going to write assembler thread-switching code for every processor under the sun.
Thoughts and opinions would be welcome.
Jill
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
