Re: Monoculture
On Wed, Oct 01, 2003 at 02:24:00PM -0400, Ian Grigg wrote: Matt Blaze wrote: I imagine the Plumbers Electricians Union must have used similar arguments to enclose the business to themselves, and keep out unlicensed newcomers. No longer acceptable indeed. Too much competition boys? Rich, Oh come on. Are you willfully misinterpreting what I wrote, or did you honestly believe that that was my intent? Sadly, there is a shared culture amongst cryptography professionals that presses a certain logical, scientific viewpoint. So is being logically and scientific is a bad way to do cryptography? Maybe you would rather some sort of more 'post-modern', 'liberal' or 'free market' cryptography? What is written in these posts (not just the present one) does derive from that viewpoint and although one can quibble about the details, it does look very much from the outside that there is an informal Cryptographers Guild in place [1]. Bollocks. Anyone is free to learn and practice (in the 'western' world, and many other countries) cryptography. Some people are just better at it, and many of those people are recognized for being better or more experienced. By your argument any group that has education and/or training is a guild. Heaven forbid CS and IT types look at the history of their own field. The guild would like the application builder to learn the field. They would like him to read up on all the literature, the analysies. To emulate the successes and avoid the pitfalls of those protocols that went before them. The That sounds like a progressive, enlightened way of doing business, at least trying to avoid known mistakes, and trying to discover new ones. None of that is likely to happen. The barrier to entry into serious cryptographic protocol design is too high for the average builder of new applications [2]. He has, after all, an application to build. Which is why the implmentation is different from protocol design, except for the insecure application developer. to boot. What is not nice is that there is no easy way to work out which code to use, and the protocols are not so easy to understand. It's nice that we have an open Cryptography is hard; suck it up. That is not a reason to act irrational and encourage using known weak or flawed methods, when we do have better known methods. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
anonymous DH MITM
Stupid question I'm sure, but does TLS's anonymous DH protect against man-in-the-middle attacks? If so, how? I cannot figure out how it would, and it would seem TLS would be wide open to abuse without MITM protection so I cannot imagine it would be acceptable practice without some form of security. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Tinc's response to Linux's answer to MS-PPTP
On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote: Truncated MAC tinc will continue to use only the first 32 bits by default. Simply put this is unacceptable from a security standpoint. The view taken is that the extra 128 bits represents a significant overhead in the communication. So I did the math, sending the extra 128 bits over a 52kbs It appears Guus Sliepen (and/or Ivo Timmermans) are worried about the tinc protocol overhead per packet. This reduces the size of the data payload per packet, which could impact perforcemance due to IP fragmentation. Because the IP packet length is often restricted due to Ethernet frame size (1500 bytes), it can is more efficient to design the protocol so each UDP datagram is a full IP packet (1500 bytes Ethernet frame minus the 20 bytes for IP header, and 8 bytes for the UDP header) with a payload of 1472 bytes. Perhaps a HMAC per chunk, rather than per the payload of a single UDP datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of payload may work. This will increase latency. Authentication protocol This should be redone from scratch, I would look at either using Diffie Hellman Key Exchange combined with digital signatures or the updated Needham Schroeder Public Key Protocol. Exchange two symmetric keys, one used for bulk data encryption, the other used for the HMAC authentication. [VPNs] work best with unreliable datagrams U, do you realize how dumb that sounds? I expect this is a reference to Why TCP Over TCP Is A Bad Idea http://sites.inka.de/~bigred/devel/tcp-tcp.html Both SSL and SSH have had their security problems . . , as perfect as Peter Gutmann would let us believe. They may not be perfect but in neither case can Mallet do as much damage as easily, even the recent break in OpenSSH did not allow a compromise as big as even the smallest of the problems briefly explored in tinc. Oh, and they fixed their flaws. SSHv1 is not recommended for use at all, and most systems use SSHv2 now which is based upon a draft IETF standard. SSL went through SSLv1, SSLv2, SSLv3, TLSv1.0, and TLSv1.1 is a draft IETF standard. If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their high tolerance for unncessary weakness, I think tinc 2.0 could end up being a secure piece of software. I hope Guus and Ivo circulate their version 2.0 protocol before they do any coding, so that any remaining flaws can be easily fixed in the paper design without changing a single line of code, saving time and effort. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
