Re: Monoculture

2003-10-01 Thread M Taylor
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?
  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 

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

2003-10-01 Thread M Taylor

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

The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

Re: Tinc's response to Linux's answer to MS-PPTP

2003-09-27 Thread M Taylor
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

  [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

  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

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]