minssl (was: Registration requests)

[ This is long and offtopic. Mail-Followup-To set. ]

> "ucspi-s"?

 ... and use "S" as the PROTO environment variable ? It's hard to guess
from that name what the protocol is. :)


> !  i've been waiting for this.

 Stay cool. It's not over yet, I'm just trying to register a name :)
 Anyway, I hate vaporware, so I'm trying not to talk too much about
unfinished projects ; but I have fair confidence in this one, so I can
answer some of your questions - don't expect the thing to be out too
soon, though. (Last time I talked about it, I said "expect a release
in July or August" - and now September seems almost hopeless. Duh.)


>  what about the interface, is is abstract enough, so that people could
> use other libraries

 No. If you need abstraction, generality, or power, then by all means
go for SSL: it was made for that.
 I don't want to be able to choose between AES or Blowfish or 3DES or
whatever. I want to have a tool that works, that's simple to use, that
I understand from A to Z in order to be able to fix bugs as soon as they
are reported, and that doesn't eat 600 KB of RAM when it doesn't need to.
That means choosing a set of algorithms and sticking to them: keep it
simple, stupid.
 Designing a secure protocol is *really* not an easy thing ; there is an
awful lot of silly mistakes you can make. Building the minssl chain,
with the one set of tools that I chose, was difficult enough ; when I
showed him my first try, a cryptologist friend of mine instantly pointed
out several weaknesses I never would have thought of. Oops. I had to
work on my theoretical background, and to have the algorithm reviewed
by two independent cryptologists, just to make sure that *that one*
algorithm was secure enough. The same amount of work would be needed
for *any* other supported library, or algorithm.
 I have neither the expertise, nor the resources of the SSL people.
They can manage complex and powerful cryptographic software, which is a
tremendous work ; I cannot, and I don't want to.


> is there library access?

 No. As I said, minssl (or whatever) is not a cryptographic tool, but a
networking tool. If you need library access, then directly use the
crypto tools: the nistp224, hash127 and RC4 interfaces are really nice
and simple. minssl doesn't add anything to that, except maybe hmac127
("how to implement some HMAC with hash127 and RC4") which was a piece
of cake to write.
 One of the main goals was to *eliminate* the need for library access,
by making the command-line interface as simple as possible. Instead of
typing "tcpclient host port blah" and "tcpserver ip port blahd", you type
"tcpclient host port minssl blah" and "tcpserver ip port minssld blahd"
(with some quirk to have minssld read a private key file, of course)
and boom, you got a secure channel instead of a cleartext one, without
blah and blahd having to know. Would a library be useful here ?


>  also, if it is based on nistp244, hash127 and RC4,
> i'd expect it to be _very_ fast.  do you have data on it's speed?

 Not yet. I expect it to be fast, too, but I'm not a benchmarking guy -
I'll probably leave the tests to you. Performance is important, but
only second to maintainability ; minssl has been optimized for
simplicity, not speed, and there are several places where I could
obviously gain some time, at the expense of source code readability -
which I will not trade.


> last, but not least:  nistp244 has this interesting feature:  people
> can create shared secrets.  has this feature been retained or made use
> of in minssl?

 I don't quite understand your question.
 To set up a secure tunnel, you need to share a secret. The *purpose* of
nistp224 is to share secrets. minssl uses nistp224 to share secrets,
because it's fast, small (for public-key cryptography software), and
most important, easy to use and understand.

-- 
 Ska