LibTomNet [v0.01]

[Matthew Byng-Maddick]

On Tue, Jul 08, 2003 at 05:31:45PM -0700, Eric Rescorla wrote:
> All else being equal, a protocol which provides more security
> is better than a protocol which provides less. Now, all things
> aren't equal, but if you can offer substantially more security
> with only a modest increase in code complexity, that's generally
> a good thing. Where hard tradeoffs have to be made is when
> the users are inconvenienced. A little additional programming
> doesn't seem like a high cost at all.

I agree with this.

> I don't find this sort of "sure, it's nowhere near as secure as
> secure as SSL, but it takes up a little less space" argument
> very compelling at all.

To my mind, one of the things that's been unstated in this thread is
that Tom should have looked at the protections involved in the SSL
streams (all the anti-replay, message integrity etc), but concentrated
on stripping down the unnecessary overhead of, for example, ciphersuite
negotiation and other bits of protocol which are the plumbing part of
SSL rather than the cryptographic parts.

As someone who has read parts of the OpenSSL 0.9.7 source, I'm sure
that it is possible to implement SSL with less obscurity layers than
the general purpose library. If you can skip out the cipher and protocol
parameter negotation then you can probably reduce the complexity down to a
truly manageable level (rather than a possible nasty in the state
machine (he says, thinking back to the vulnerability in OpenSSL a year
ago)) and hopefully without changing the security of the stream protocol
significantly.

Of course that doesn't help if what you really need is a general-purpose
secure socket transport ;-)

MBM

-- 
Matthew Byng-Maddick         <mbm at colondot.net>           http://colondot.net/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com