Re: LibTomNet [v0.01]
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 <[EMAIL PROTECTED]> http://colondot.net/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
[Moderator's note: I've been choking back the LibTomNet argument but I thought Steve's specific references here are interesting, even if the point has already been made. --Perry] In message <[EMAIL PROTECTED]>, tom st denis w rites: > >The RFC looks like it was written by a member of the ACLU and done at >an hourly rate of some sort. It contains no test vectors, no sample >source code and generally is not enough information to code a compliant >SSL protocol. What does the ACLU have to do with it? "Be liberal in what you accept?" > >Not only is my code way smaller than a compliant SSL library but it is >also simpler. There are only eight functions in LibTomNet and of >LibTomCrypt you only need a half dozen at most [setup the prng, RSA key >gen, export/import]. In otherwards my code is [should be] very easy to >work with since there is a minimum of clutter to get in the way. > Tom, I don't know you, and I don't know what your background in crypto protocol design is. It's an *exceedingly* subtle art. A few months ago, I went back and reread the original Needham-Schroeder paper, from December 1978. It is, as far as I know, the first paper in the open literature on cryptographic protocols. In it, the authors warn that they think that this is a very difficult area, and that subtle flaws will occurs. That's one of the more amazing instances of prescience I've seen. Let me briefly review the history of that protocol. As I said, it was published in December, 1978. It had symmetric and asymmetric versions of the protocol. The latter -- taking into account certificates, which had not yet been invented -- was only three lines long. In August 1981, Denning and Sacco published a paper describing a comparatively subtle flaw in the protocol; they also proposed a fix. In 1994, Abadi and Needham described a flaw in the Denning/Sacco replacement. (That flaw might have been described in 1987, but I'm traveling and don't have my library with me...) In 1996, a new flaw was found in the original Needham-Schroeder asymmetric variant -- a flaw that was blindingly obvious once pointed out. Tell me -- why should anyone trust your new protocol, given the history of one of the most-studied protocols in the field? SSLv3 has had a lot of scrutiny. Has yours? > >At anyrate LibTomNet is not an SSL replacement. It's a library for >developers who need simple to work with secure sockets. That's what SSL is. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
Ian Grigg <[EMAIL PROTECTED]> writes: > Eric Rescorla wrote: > > > My logic is that if you're going to create something new, it should > > be better than what already exists. > > Right. But better is not a binary choice in real > life. SSL is only "better" if it exceeds all > requirements when compared against a product > that has only those requirements. > > One needs to look at the requirements. Tom's > requirements didn't include message integrity, > if I saw correctly, because he had something > in there at a higher layer that covered him > there. That's good. That's certainly not true. He had a message integrity construct. It just didn't include anti-replay measures. > Does he require replay protection? Is he worried > about MITM? What about authenticity? These all > need to be established before you can compare any > protocol. > > The whole world doesn't want or need perfect > channel security. That's because some parts of > the world have different needs. Actually, I think this attitude is generally unproductive. 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 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. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
Eric Rescorla wrote: > My logic is that if you're going to create something new, it should > be better than what already exists. Right. But better is not a binary choice in real life. SSL is only "better" if it exceeds all requirements when compared against a product that has only those requirements. One needs to look at the requirements. Tom's requirements didn't include message integrity, if I saw correctly, because he had something in there at a higher layer that covered him there. That's good. Does Tom require certs? No, or *even better* he explicitly outsourced that requirement to another layer, thus allowing the protocol to be simpler. This is a great thing, and my reading of the protocol of SSL - from Eric's book - indicates that SSL would benefit from it too. Does he require replay protection? Is he worried about MITM? What about authenticity? These all need to be established before you can compare any protocol. The whole world doesn't want or need perfect channel security. That's because some parts of the world have different needs. -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
At 05:42 PM 7/8/2003, Thor Lancelot Simon wrote: I believe the Certicom library is somewhere around there in size, and it is a pretty extensive implementation. Costs money though. ;-) IIRC, the embedded SSL library I wrote (with Chris Hawk) at Certicom was < 64K of 68K code (we originally wrote it for PalmOS devices), including all crypto, for a fully-compliant SSL 3.0 & X.509v3 implementation (client-side SSL only, with a profiled subset of SSL ciphersuites and X.509 features, of course). And it could run with a RAM usage of substantially less than 10K/connection. And we wrote it in less than a month (it was our third or fourth time implementing SSL and X.509, though). The complete Certicom library is somewhat bigger, but it's got a lot of flexibility, (modular crypto interface, etc.), and code size wasn't a concern on desktop/server platforms. - Tim - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 02:20:46PM -0700, Eric Murray wrote: > > For comparison purposes, I have a copy of an SSLv3/TLS client library > I wrote in 1997. It's 56k of (Intel Linux) code for everything > except RSA. That includes the ASN.1 and X.509 parser. > Implementing the server-specific parts would add only another > couple k. This was done for a handheld computer but runs on > unix as well. I believe the Certicom library is somewhere around there in size, and it is a pretty extensive implementation. Costs money though. ;-) > OpenSSL is huge because it's also a general purpose crypto lib, supports > a bunch of hardware and a bunch of algorithms, SSLv2 (ew), old apis, > non-blocking, etc etc. It's also hideously overabstracted. That, to my mind, is why it's both hard to use and hard to maintain. Unfortunately, its "API" is the only one that is in wide use on Unix systems, which means that any alternative would probably be forced to duplicate a frightening amount of OpenSSL's internal complexity in order to present its _external_ complexity. Thor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 04:32:41PM -0400, Thor Lancelot Simon wrote: > I trimmed OpenSSL down to just TLSv1 and only the FIPS-140 conformant > algorithms for a FIPS-140 conformance project at ReefEdge (and yes, [..] > The result was still several hundred kilobytes -- actually, I don't > have exact numbers handy but I believe it was more than a megabyte > in size. OpenSSL is not the TLS implementation I would use if I had > any other free option that offered reasonable performance. :-( For comparison purposes, I have a copy of an SSLv3/TLS client library I wrote in 1997. It's 56k of (Intel Linux) code for everything except RSA. That includes the ASN.1 and X.509 parser. Implementing the server-specific parts would add only another couple k. This was done for a handheld computer but runs on unix as well. OpenSSL is huge because it's also a general purpose crypto lib, supports a bunch of hardware and a bunch of algorithms, SSLv2 (ew), old apis, non-blocking, etc etc. Eric - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 09:18:53PM +0100, M Taylor wrote: > On Tue, Jul 08, 2003 at 12:19:54PM -0700, Eric Rescorla wrote: > > > > As I said before, the problem here isn't SSL. Rather, it's the way > > that OpenSSL does things. Now, it would be a real contribution for > > you to write a simple wrapper for OpenSSL. I've seen people do stuff > > like that, but it's generally too custom for general use. > > stunnel (www.stunnel.org), which is an "universial SSL wrapper". > > So perhaps Tom could could write a EZ-OpenSSL wrapper, which remove > legacy options (disable SSLv2 and SSLv3, just TLSv1), limit algorithm > choice to sensible defaults, and ensure the programmer has as decent > as available random numbers. The problem isn't just the interface that OpenSSL presents to the application programmer (which is lousy, and which in a lot of cases is totally undocumented; it also has the "Kerberos problem" which is to say that to do cryptographically necessary things it is often necessary to use internal or deprecated functions directly, and these change from release to release... ugh!) it's also how it's implemented. I trimmed OpenSSL down to just TLSv1 and only the FIPS-140 conformant algorithms for a FIPS-140 conformance project at ReefEdge (and yes, we did then have that version of OpenSSL tested and certified, but no, you can't have it for free ;-)). It was not so hard, but it was immensely time-consuming and I had to learn a totally unreasonable amount about OpenSSL's internals to actually ensure that all the nonconformant algorithms were disabled (in some cases it would have been impractical to not build them at all, unfortunately). The result was still several hundred kilobytes -- actually, I don't have exact numbers handy but I believe it was more than a megabyte in size. OpenSSL is not the TLS implementation I would use if I had any other free option that offered reasonable performance. :-( Thor - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 11:53:13AM -0700, Eric Rescorla wrote:
> Ian Grigg <[EMAIL PROTECTED]> writes:
>
> > It's not just you. The field seems to be evenly
> > divided between those who view SSL as a mess, and
> > those who view it as the only sane choice because
> > so much attention has been put on it.
> I'm not sure why you think that these two views are
> inconsistent. Sure, SSL embodies lots of mistakes, and I'm hard on
> some of those in my book. However, my experience is that when people
> sit down and try to do a better job, they generally bungle it. Tom's
> attempt is only the latest example.
Attempts to do new stuff should not be discouraged.
But like home-made ciphers, they should be viewed as interesting
learning exercises rather than serious secure protocols.
> > The main thing that reduces SSL's applicability to
> > real world problems come down to the assumption of
> > certificates as part and parcel of the security
> > model.
> This is just wrong. There are extensions to SSL to support Kerberos,
> SRP, and even primitive shared keys (see Peter Gutmann's latest draft
> on this topic).
Unauthenticated Diffie-Hellman has been in SSLv3 since the beginning.
Rejecting SSL because it "uses certifictes" is either a result
of ignorance of the spec or an excuse for re-inventing.
> > It's definately not just you - but one of the reasons
> > that it feels like that is that the SSL supporters
> > tend to protect their franchise very aggresively.
> It's not just SSL. I've beaten up on people who were trying to
> reinvent S/MIME in this very forum. It's just that people seem to try
> to reinvent SSL about 5 times more often than they try to reinvent
> anything else. My guess is that that's because the channel security
> problem *looks* so simple and so it seems like it should be easy to do
> something simpler and better than SSL.
If you are into wheels, it's more fun to (re-)invent the wheel the wheel
than it is to use the existing wheels laying about. The posters here
are wheel geeks ("look, I can build a 12-spoke wheel!") who are not
interested in the reliabilty of the bicycles that the wheels are used on.
> > Nonsense. We aren't even up to being the C-team,
> > we don't make the team. And we won't ever until
> > we cast off the shackles of rote acceptance, and
> > start challenging SSL on its inadequacies.
If you start with the same assumptions you will wind up
with something that looks very similar to SSL. Once you have discovered
and addressed all the same holes and pitfalls that is.
While it's a fun learning exercise, it's not useful to the rest of
the world... SSL, because it has had more review than your protocol
will ever get, will be more secure.
The only way to end up with something significantly different
is to address a different set of requirements... and more different
than "no certificates".
A good place to start is Eric's _SSL and TLS_ book.
How can you make something better without understanding the mistakes
of the past?
Eric
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
On Tue, Jul 08, 2003 at 12:19:54PM -0700, Eric Rescorla wrote: > tom st denis <[EMAIL PROTECTED]> writes: > > > > My logic is that if you're going to create something new, it should > > > be better than what already exists. There is precious little > > > evidence that libtomnet fills that bill. > > > > LibTomNet has eight functions and one data type in the API. To a > > complete stranger that is a nice welcome change than say all the > > constants, functions, structures in SSL. > > As I said before, the problem here isn't SSL. Rather, it's the way > that OpenSSL does things. Now, it would be a real contribution for > you to write a simple wrapper for OpenSSL. I've seen people do stuff > like that, but it's generally too custom for general use. stunnel (www.stunnel.org), which is an "universial SSL wrapper". So perhaps Tom could could write a EZ-OpenSSL wrapper, which remove legacy options (disable SSLv2 and SSLv3, just TLSv1), limit algorithm choice to sensible defaults, and ensure the programmer has as decent as available random numbers. Or rewrite LibTomNet to match the basic PROTOCOL concepts of TLS, without the legacy compatability, and reduce/remove algorithm negotation, etc. No need to actually be compatible with TLS, just to use the same protocol concetps. Until Tom's libtomnet known/tested is secure from all known attacks on SSL/TLS, he should refrain from calling it 'secure' since he cannot be reasonable certain that it is in fact secure. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > tom st denis <[EMAIL PROTECTED]> writes: > > > The point I'm trying to make is that just because a fairly standard > > > product exists doesn't mean diversity is a bad thing. Yes, people > > may > > > fail to create divergent products but that isn't a bad thing. You > > > learn from the faults and create a better product. I mean by your > > > logic we would all drive Model T cars since well... diversity is > > bad. > > > The model T exists! > > My logic is that if you're going to create something new, it should > > be better than what already exists. There is precious little > > evidence that libtomnet fills that bill. > > To you. You know SSL inside and out. > > LibTomNet has eight functions and one data type in the API. To a > complete stranger that is a nice welcome change than say all the > constants, functions, structures in SSL. As I said before, the problem here isn't SSL. Rather, it's the way that OpenSSL does things. Now, it would be a real contribution for you to write a simple wrapper for OpenSSL. I've seen people do stuff like that, but it's generally too custom for general use. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
Ian Grigg <[EMAIL PROTECTED]> writes: > tom st denis wrote: > > > > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > > [Standard rant follows... :)] > > > I'm trying to figure out why this is a good idea even in principle. > > > > Maybe its just me but SSL is overly complicated. > > It's not just you. The field seems to be evenly > divided between those who view SSL as a mess, and > those who view it as the only sane choice because > so much attention has been put on it. I'm not sure why you think that these two views are inconsistent. Sure, SSL embodies lots of mistakes, and I'm hard on some of those in my book. However, my experience is that when people sit down and try to do a better job, they generally bungle it. Tom's attempt is only the latest example. > The main thing that reduces SSL's applicability to > real world problems come down to the assumption of > certificates as part and parcel of the security > model. This is just wrong. There are extensions to SSL to support Kerberos, SRP, and even primitive shared keys (see Peter Gutmann's latest draft on this topic). > It's definately not just you - but one of the reasons > that it feels like that is that the SSL supporters > tend to protect their franchise very aggresively. It's not just SSL. I've beaten up on people who were trying to reinvent S/MIME in this very forum. It's just that people seem to try to reinvent SSL about 5 times more often than they try to reinvent anything else. My guess is that that's because the channel security problem *looks* so simple and so it seems like it should be easy to do something simpler and better than SSL. Incidentally, I suspect that this is what was going through Hickman's head when he designed SSLv2, which is no doubt why it's such a botch. > Which is a total crock. If SSL can't make up its > credibility in the open market place, then it isn't > worth idolising. Are you on crack? SSL HAS won in the market place. It's only the amateurs who persist on trying to reinvent it. > Nonsense. We aren't even up to being the C-team, > we don't make the team. And we won't ever until > we cast off the shackles of rote acceptance, and > start challenging SSL on its inadequacies. > > Tom, you are not alone! Dabble on! You know, Ian, this argument would be a lot more convincing if the people who tried to reinvent SSL didn't always botch the job. I've yet to see one of these things that didn't have glaring flaws that wouldn't have been made by someone who had taken the time to really understand SSL. No doubt that's because once you've spent some time thinking about the problem you get driven to roughly the same set of design decisions SSL embodies. This isn't because the SSL authors were such geniuses, but rather because there's basically one best way to do things. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis wrote: > > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > [Standard rant follows... :)] > > I'm trying to figure out why this is a good idea even in principle. > > Maybe its just me but SSL is overly complicated. It's not just you. The field seems to be evenly divided between those who view SSL as a mess, and those who view it as the only sane choice because so much attention has been put on it. (That's just my seat of the pants feel for it, in gauging the public and private responses to the series of rants on SSL I've written. And it isn't just a recent development, I've known other far more competent (than me) cryptoplumbers who were dissatisfied with SSL, going back as far as 1997.) Using SSL as a base for a new set of requirements seems to be about as complicated as a competant cryptoplumber doing his own. Obviously, SSL will give you a jumpstart in security over your homegrown crypto, but less obviously, the complications and misturns built into SSL make tuning it to your application a much harder task, and achieving a unified security model is difficult because it's not a simple starting point. The main thing that reduces SSL's applicability to real world problems come down to the assumption of certificates as part and parcel of the security model. Also, the threat model is unrealistic, and the consequent security properties seem more to derive from "what we can do" rather than "this is what your application demands and needs." It's definately not just you - but one of the reasons that it feels like that is that the SSL supporters tend to protect their franchise very aggresively. Which is odd, really, I haven't myself worked out why the supporters of a particular protocol are so adamant that one should not experiment in a field as complicated and challenging as crypto. Their attitude is religious, it is tantamount to saying that you shouldn't dare to assault the ivory tower. SSL is the officially sanctioned way of doing Internet crypto. Capice? Which is a total crock. If SSL can't make up its credibility in the open market place, then it isn't worth idolising. If you looked at it - and you say you did - and concluded you could do better on your own, then more power to you. And us all. An entire generation of crypto engineers have been fed this notion that they needn't bother with their own, which has had the net result of reducing crypto knowledge, reducing security, and leaving the net reliant on an infrastructure that just can't meet its own needs, let alone the needs of users. Somebody said we were the A-team. John Gilmore, I think, but that's from memory. Nonsense. We aren't even up to being the C-team, we don't make the team. And we won't ever until we cast off the shackles of rote acceptance, and start challenging SSL on its inadequacies. Tom, you are not alone! Dabble on! -- iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
I think Eric has done a slam-dunk, and perhaps our moderator will close this thread of dicussion. :) Eric's cursory examination has shown that Tom's code has a number of security flaws (that can be fixed) and weaknesses (that are apparently deliberate), in code that's not much smaller than SSL, and is certainly less feature-ful. Congrats on the learning exercise, Tom. Regretablly the big lesson has avoided you so far. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > > > Heck, if you could find a security flaw in LibTomNet [v0.03] I'll > > buy > > > you a beer. > > Your protocol does not use appear to have any protection against > > active attacks on message sequence, including message deletion, > > replay, etc. True, the attacker can't inject *predictable* > > plaintext, > > but he can inject garbage plaintext and have it accepted as real. > > No he can't. You need a correct HMAC for the data to be accepted. > This allows a replay attack which I should fix. One beer. > > Ultimately though the plaintext won't match if you replay though so its > only half a bug [though a bug that must be fixed]. Uh, this is exactly what I said. If you delete messages or replay them, they will pass through the HMAC and be decrypted (thus giving you unpredictable garbage) and passed to the application layer. > > Your protocol is susceptible to truncation attack via TCP FIN > > forging. > > I don't even know what that is but my protcol must read an entire block > before parsing it. Yes, but if I forge a TCP FIN in between blocks, you can generate a fake connection close. This is a problem if the protocol layered over top uses connection close to indicate end of data as (say) HTTP does. That's why SSLv3 and above include a close_notify message in the alerts. > > Your server doesn't generate any random values as part of the > > handshake, > > thus, leaving you open to full-session replay attack. > > Which is why people should use some authentication scheme ontop of > this. Note that the server has no clue who you are after making the > connection. This is intentional.\ This doesn't always help, unfortunately. Consider the case where you're using a replayable authentication scheme such as passwords over your encrypted session. This is perfectly natural and people do it with SSL all the time. So, the attacker captures you doing some transaction replays it to the server. Congratulations, you've now done it twice. The standard procedure to prevent this (used in SSL, IKE, etc.) is for the server to send the client a nonce in his hello message, thus preventing client-side replay. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
--- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > Heck, if you could find a security flaw in LibTomNet [v0.03] I'll > buy > > you a beer. > Your protocol does not use appear to have any protection against > active attacks on message sequence, including message deletion, > replay, etc. True, the attacker can't inject *predictable* > plaintext, > but he can inject garbage plaintext and have it accepted as real. No he can't. You need a correct HMAC for the data to be accepted. This allows a replay attack which I should fix. One beer. Ultimately though the plaintext won't match if you replay though so its only half a bug [though a bug that must be fixed]. > Your protocol is susceptible to truncation attack via TCP FIN > forging. I don't even know what that is but my protcol must read an entire block before parsing it. > Your server doesn't generate any random values as part of the > handshake, > thus, leaving you open to full-session replay attack. Which is why people should use some authentication scheme ontop of this. Note that the server has no clue who you are after making the connection. This is intentional.\ So if you are in the area [or at Crypto'03] I'll buy you a beer. Tom __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > In other words, this is just an exercise in Not Invented Here. > > Wonderful. > > Oh, ok so I need your permission? No, you don't need my permission. You can do any fool thing you want. It would just be nice if you were spending effort filling some actual need, rather than reinventing the wheel. > Who gave Netscape permission to > write SSL? [or whoever invented it] Netscape. However, the situation was different then. There was actually a market niche that SSL didn't fill. It has yet to be established that LibTomCrypt is in that position. > Generally I agree that homebrew crypto is a bad idea but I think you > are undervaluing my knowledge in the field. I'm not some two-bit IT > specialist trying to make a quick buck. You don't seem to understand the issue. It has nothing to do with how competent you are and everything to do with the fact that people make mistakes and so homebrew stuff is bad when you can avoid it. Everyone I know who has worked in this field has made a bunch of mistakes and depends on others to catch them. > My library *really* only has eight functions, it *really* is only 13KB > [excluding the crypto], it *really* provides secure sockets. And I claim that SSL implementations can be gotten down to very nearly that size, especially if you're willing to compromise a lot of the features, so what virtue is your library providing? > Just because it isn't SSL doesn't mean its incapable of being secure. No, it just means that it's never going to get the kind of security analysis that SSL has, which means that there are probably a bunch of undiscovered holes. > > Moreover, your original message said that you intended to use > > SSL, but as you yourself admit, you don't understand it and yet > > you feel comfortable holding forth about it's merits compared > > to your brand new protocol. Huh? > > Yeah, because I'm not going to sit and study 67 pages for more than a > day to figure out how to send a key or perform key exchange. It turns out that doing a principled job is a lot more complicated than doing key exchange. That's one of the things that one discovers when actually writing a full protocol rather than just whipping something together. > To sum up, I do agree that homebrew stuff is generally of lower quality > than peer-reviewed standards but I think you're too easily dismissing > all other works because they're not your own. To that end I call you > an elitist pig. Seeing as I didn't write SSL, I'm just the document editor, that just makes you look silly. > Heck, if you could find a security flaw in LibTomNet [v0.03] I'll buy > you a beer. Your protocol does not use appear to have any protection against active attacks on message sequence, including message deletion, replay, etc. True, the attacker can't inject *predictable* plaintext, but he can inject garbage plaintext and have it accepted as real. Your protocol is susceptible to truncation attack via TCP FIN forging. Your server doesn't generate any random values as part of the handshake, thus, leaving you open to full-session replay attack. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > --- Eric Rescorla <[EMAIL PROTECTED]> wrote: > > tom st denis <[EMAIL PROTECTED]> writes: > > > Two weeks ago I sat down to learn how to code my own SSL lib [key > > on > > > being small]. Suffice it to say after reading the 67 page RFC for > > SSL > > > 3.0 I have no clue whatsoever how to implement SSL. > > Funny, none of the 30 or so other people who have done SSL > > implementations had any problem. > > Arrg whatever. I really don't give a hoot what you think. > > What I don't get is you guys who are presumably a smart bunch can't > figure out that > > I > > AM > > NOT > > TRYING > > TO > > REPLACE > > SSL. > > I'm just writing a simple library to provide secure sockets. That's > it, that's all. In other words, this is just an exercise in Not Invented Here. Wonderful. > Believe it or not, this may come as a surprise to you, but not everyone > requires standsrd compliant protocols. If the past 20 years of security work have taught us anything, it's the value of standardized tools that get a lot of review so that we can be confident that they're not totally hosed. When people go off and invent their own stuff without good reason, that's not good security practice. That's fine if they're just screwing around, but when they come up with all sorts of bogus reasons why people might want to use their homegrown stuff instead of the standard stuff, that's not so fine. Moreover, your original message said that you intended to use SSL, but as you yourself admit, you don't understand it and yet you feel comfortable holding forth about it's merits compared to your brand new protocol. Huh? -Ekr P.S. You claimed earlier that you didn't think RFC 2246 was clear enough to write a complaint implementation. I was sincere in asking what you find underspecified. It's my job to make it as complete as possible. -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > Two weeks ago I sat down to learn how to code my own SSL lib [key on > being small]. Suffice it to say after reading the 67 page RFC for SSL > 3.0 I have no clue whatsoever how to implement SSL. Funny, none of the 30 or so other people who have done SSL implementations had any problem. > The RFC looks like it was written by a member of the ACLU and done at > an hourly rate of some sort. It contains no test vectors, no sample > source code and generally is not enough information to code a compliant > SSL protocol. I'd be interested to know in what way you believe the TLS RFC is not sufficient to write a complaint implementation. Except for some edge cases, it's fully specified as far as I know. Anyway, I'm the document editor so it's my job to fix it. This isn't an invitation to complain more about the writing quality (for which I'm not responsible in any case). But if you think that there's actually something that's unspecified, I want to know about that. As for the complexity of TLS, that's what happens when you design a general protocol. I can pretty much guarantee you that every part of TLS has been used by someone at one time or anotehr. > My 64KB demo includes the server, the client, all the crypto [including > a full RSA implementation] and the LibTomNet protocol. I could make > the demo smaller by manually trimming LibTomCrypt. And we got SSLv2 and v3 in <100 kb without trying particularly hard, using BSAFE, which is enormous. This isn't much of an argument, really. > Not only is my code way smaller than a compliant SSL library but it is > also simpler. There are only eight functions in LibTomNet and of > LibTomCrypt you only need a half dozen at most [setup the prng, RSA key > gen, export/import]. In otherwards my code is [should be] very easy to > work with since there is a minimum of clutter to get in the way. > > I mean just download a copy [v0.03 is the latest] and check out the > demo [demos/ex1.c]! > > At anyrate LibTomNet is not an SSL replacement. It's a library for > developers who need simple to work with secure sockets. This striked me as quite confused. What makes developer's lives simple is simple APIs, not simple implementations. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
--- Eric Rescorla <[EMAIL PROTECTED]> wrote: > [Standard rant follows... :)] > I'm trying to figure out why this is a good idea even in principle. Maybe its just me but SSL is overly complicated. I've been dabbling with crypto since I was sixteen. I've written several popular libs already [LibTomCrypt and LibTomMath] so while I'm not a PhD in crypto I think I'm fairly competent enough to sit down and implement an algorithm per specs [to a limit]. Two weeks ago I sat down to learn how to code my own SSL lib [key on being small]. Suffice it to say after reading the 67 page RFC for SSL 3.0 I have no clue whatsoever how to implement SSL. The RFC looks like it was written by a member of the ACLU and done at an hourly rate of some sort. It contains no test vectors, no sample source code and generally is not enough information to code a compliant SSL protocol. So I wrote LibTomNet. It provides exactly what I wanted and is very simple to understand and work with. > I've seen <100k SSL implementations and that included the ASN.1 > processing for certs. I would imagine that one could do a compliant > SSL implementation that used fixed RSA keys in roughly the same > code size as your stuff. My 64KB demo includes the server, the client, all the crypto [including a full RSA implementation] and the LibTomNet protocol. I could make the demo smaller by manually trimming LibTomCrypt. Not only is my code way smaller than a compliant SSL library but it is also simpler. There are only eight functions in LibTomNet and of LibTomCrypt you only need a half dozen at most [setup the prng, RSA key gen, export/import]. In otherwards my code is [should be] very easy to work with since there is a minimum of clutter to get in the way. I mean just download a copy [v0.03 is the latest] and check out the demo [demos/ex1.c]! At anyrate LibTomNet is not an SSL replacement. It's a library for developers who need simple to work with secure sockets. Tom __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
tom st denis <[EMAIL PROTECTED]> writes: > The lib uses RSA for key exchange [and the client may scrutinize the > key before making the connection via a callback], AES-128-CTR [two > different keys for each direction] and SHA1-HMAC. The niche of the lib > is that my library compiles to a mere 10KB. Add SHA1, AES, HMAC, RSA > and LTM and you get 60KB demo apps Ideally you should build LTC > without mpi.o and link against both LTC and LTM. > > The lib does not implement any other protocol like SSH/SSL/TLS [etc]. > > I have to mention this in good conscience. I ==>STRONGLY<== DISCOURAGE > people from using this library in fielded systems. I've only been > working on it for a day and I wouldn't be surprised if there were > numerous bugs or points of attack [I've fixed a dozen since last > night]. [Standard rant follows... :)] I'm trying to figure out why this is a good idea even in principle. I've seen <100k SSL implementations and that included the ASN.1 processing for certs. I would imagine that one could do a compliant SSL implementation that used fixed RSA keys in roughly the same code size as your stuff. -Ekr -- [Eric Rescorla [EMAIL PROTECTED] http://www.rtfm.com/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: LibTomNet [v0.01]
> The lib does not implement any other protocol like SSH/SSL/TLS [etc]. Can you explain why someone would prefer your new crypto mechanisms over the well-studied SSL/TLS, IPsec, etc? From a security viewpoint; let's call app size irrelevant. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
LibTomNet [v0.01]
[repost from sci.crypt] Oh no, not another LibTom thing! arrg! First the temp url... http://libtomcrypt.org/net/ I'll get a net.libtomcrypt.org VHOST setup shortly. LibTomNet is a library designed to provide streaming TCP/IP privacy and authentication. It uses LibTomCrypt as the crypto provider. The lib uses RSA for key exchange [and the client may scrutinize the key before making the connection via a callback], AES-128-CTR [two different keys for each direction] and SHA1-HMAC. The niche of the lib is that my library compiles to a mere 10KB. Add SHA1, AES, HMAC, RSA and LTM and you get 60KB demo apps Ideally you should build LTC without mpi.o and link against both LTC and LTM. The lib does not implement any other protocol like SSH/SSL/TLS [etc]. I have to mention this in good conscience. I ==>STRONGLY<== DISCOURAGE people from using this library in fielded systems. I've only been working on it for a day and I wouldn't be surprised if there were numerous bugs or points of attack [I've fixed a dozen since last night]. That being said the code uses fairly standard BSD style socket calls. It works in Linux and should port rather trivially to QNX, UNIX, IRIX and Win32 [among others]. What I would appreciate is if people could help and send patches to get the code to work in other OSes. I'd like to get it working in at least Linux and Win32 by next week. Tom __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
