It's worth summing up the design goals here, so nobody gets confused. Trouble is, I haven't figured out what they should all be. The main point of confusion/contention right now seem to be (1) should it be in C or C++?, (2) should it support SSL or TLS or both?
There are plenty of things I am really sure about, however. The two main design goals people seem to want are (1) lightweight, and (2) easy to use. (Plus the "obvious" goals of (3) it actually /will/ implement SSL/TLS and not something else, and (4) it shouldn't be full of bugs. I figure those go without saying).
Regarding the choice of language, I think I would want this library (or toolkit, or whatever) to be somehow different from OpenSSL - otherwise what's the point? I mean ... this may be a dumb question, but ... if people want C, can they not use the existing OpenSSL? Or is it simply that OpenSSL is too complicated to use, so a "simpler than OpenSSL" C version is required. What I mean is, I don't want to duplicate effort. That seems dumb.
C++ has many advantages, which include SECURITY advantages. Proper use of constructors, destructors, exceptions, std::strings, std::vectors, smart pointers, and so on can eliminate memory leaks, dangling pointers, buffer overruns, and just about everything else than can bring a good toolkit down. I already have a very nice, working, C++ secure big-integer library [here's one I wrote earlier]. By "secure" in this context, I mean that all big-integers get zeroed on deletion, so no crypto keys are ever left lying around in memory. Sure, these sort of things are all also possible in C, but it's so much more work to be /sure/ that every error condition is dealt with. Is embedded C++ non-existant then? I'm pretty sure it's possible to compile C++ to C (instead of to assembler) so a C++ to C wrapper can't be that difficult. (By contrast, a C to C++ wrapper would be easier, but the toolkit would have more bugs!) My inclination is still to go with C++, and figure out a way of turning it into C later if necessary ... but if majority opinion says otherwise I'll reconsider.
Now - SSL or TLS - this confuses me. From what I've read in Eric's book, SSL version 3.0 or below is called SSL, wheras SSL version 3.1 or above is called TLS. Have I misunderstood that? In any case, I note the bit in Eric's book (p73 in my edition) where it says "In general, it is expected that an implementation speaks all lesser versions" ... even if lesser versions become known to be insecure. I'm not sure I like this - and in any case, it goes against the design goal of "lightweight". If you want to implement only TLS (for example, in a closed private network where all parties are known to be using the same version of the same protocol), why should you have to lug around SSL as well? I suppose I /want/ the solution to be "allow the toolkit to generate either SSL-only, or TLS-only, or SSL+TLS" ... but what I'm not sure about is, is the "TLS-only" option forbidden by the standard?
And now some questions about SSL/TLS itself....
THE HANDSHAKE PHASE
The assumption in Eric's book, roughly translated into Alice and Bob scenarios, goes something like this: Bob (client) says hello to Alice (server). Alice sends Bob her certificate (which is basically a copy of her public key, signed by a third party, Carol). Bob validates Alice's key (which is only possible if he already has a copy of Carol's public key), and then uses Bob's (now validated) public key to start sending encrypted messages. (There's more, but that's the important part).
Now, this scenario is all very well for banks and big businesses, but I guess I want to do "SSL for the rest of us". You see, the above scenario contains a couple of assumptions. It assumes (1) that Bob does not already have Alice's key - otherwise why would she need to send it? It further assumes (2) that Bob /does/ have Carol's key, /and that he trusts Carol/. Okay, fine, but what if these assumptions aren't met? I mean, let's assume that Bob already has Alice's key. (Let's say for sake of argument that she gave it to him personally). Now this means we can save on bandwidth by not having to transmit Alice's cert ... but already there are two problems: (1) would it be a violation of the protocol to omit the cert?, and (2) without the cert, we would need some /other/ kind of message with which to replace it - one which says, simply, "Hi, this is Alice, use the copy of my key which you already have". So already I have questions - how free am I to allow variations in the handshake?
THE CIPHER SUITE
The list on page 74 of Eric's book looks a little limiting to me - not merely because the list is too short, but also because it's very design is wrong (in lumping all of the encryption ciphers together into a single 16-bit value with no internal structure). What if Alice would like to use, say, some elliptic curve function as her asymmetric algorithm?, or CAST-5 as her symmetric algorithm?, or SHA-256 as her hash function? We could maybe fix this up by adding more entries to the list, but it's a global list, so who has the authority to add entries to it? I believe that Alice and Bob should be able to communicate with whatever ciphers they wish, and should not need the permission of any global authority to do this. Are there any values in the range (0x0000 to 0xFFFF) which are reserved for private use between consenting parties?
It is even possible for Alice and Bob to use a proprietry cipher. For example, what if the chosen encryption algorithm is "one-time-pad", using a block of bits communicated out of band (e.g. via so-called quantum cryptography, or that hard-drive alternative discussed in another thread). How can this be communicated in the CipherSuite field? I would like to believe there is a way of doing this ... but if not, I'd like to know that too, so I can find a neat way of extending the protocol to /make/ it possible.
THE COMPRESSION METHOD
Exactly the same question. Alice and Bob are consenting adults, and they want to use the BZIP compression algorithm. I'm not going to tell them they can't. (I suspect though that the answer to the previous query will also answer this one).
THE CERTIFICATE
Can Alice and Bob each create their own certificates? With (for example) Alice's key signed by Bob, and Bob's key signed by Alice, as is often done in GPG? Who counts as the "Issuer" in this case? How can Alice (or a piece of software working on Alice's behalf) construct an X.500 Distinguished Name to describe herself /and be absolutely sure that it is globally unique/? On page 12 of Eric's book it explains that a DN is a sequence of RDNs, each of which only needs to be locally unique, so the whole sequence becomes globally unique. That's all very well, but it's still a global namespace overall, so who controls it? Let me be clear that Alice and Bob have no intention to give even a single penny to Verisign or any other entity, just so that they can talk to each other in private.
FINISHED
Well, that's enough questions for now. Hopefully someone can answer some of them. Encouragement is great, and I appreciate it, but practical answers to the above would be even better.
Cheers, Jill
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
