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]