[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Triple DES, Diffie-Hellman, and ECDSA


Just wanted to jump in and mention that ANSI X9.F1 voted last week to send
X9.42 (Diffie-Hellman), X9.52 (Triple DES Modes), and X9.62 (Elliptic Curve
Digital Signature Algorithm - ECDSA) to ballot after some relatively minor 
editorial changes are made.  All three documents have come a long way since 
their inception and are quite mature at this point.

Since the IPSEC group seems to be searching for definitive documents on 
Diffie-Hellman and Triple-DES in particular, I strongly encourage interested 
parties to take a look at these documents before trying to re-invent the 
wheel.  X9.62 - ECDSA is an elliptic curve version of the NIST Digital 
Signature Standard.  Both X9.42 and X9.62 are closely aligned to parallel work 
going on in IEEE P1363.

Contact information:

X9.42 (Diffie-Hellman): John Kennedy, jkennedy@cylink.com
X9.52 (Triple DES): Bill Lattin, lattin@cylink.com
X9.62 (ECDSA): Don Johnson, djohnson@certicom.ca

Regards,

-John Kennedy, jkennedy@cylink.com

Date: Tue, 8 Oct 1996 19:47:42 -0400
Message-Id: <9610082347.AA23159@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: uri@watson.ibm.com
Cc: Steven Bellovin <smb@research.att.com>, ipsec@TIS.COM
In-Reply-To: Uri Blumenthal's message of Tue, 8 Oct 1996 18:50:13 -0400 (EDT),
	<9610082250.AA18537@hawpub.watson.ibm.com>
Subject: Re: Short keys * Options, combinations, and negotiations => simplicity
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

   From: Uri Blumenthal <uri@watson.ibm.com>
   Date: Tue, 8 Oct 1996 18:50:13 -0400 (EDT)

   I don't remember exactly,  but if memory serves me, there is one more
   mode, that Eli thinks secure...Checking his home page would be useful.
   The paper: "Cryptanalysis of multiple modes" or such.

Eli's home page is:

	http://www.cs.technion.ac.il/~biham/

The paper in question ("On Modes of Operations", published in the
proceedings of Fast Software Encryption 1) can be found as:

	http://www.cs.technion.ac.il/~biham/Reports/onmodes.ps.gz

							- Ted




Message-Id: <199610090225.WAA13952@raptor.research.att.com>
To: Stephen Kent <kent@bbn.com>
cc: John Gilmore <gnu@toad.com>, ipsec@TIS.COM
Subject: Re: Short keys * Options, combinations, and negotiations => simplicity 
Date: Tue, 08 Oct 1996 22:25:53 -0400
From: Steven Bellovin <smb@research.att.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk

	 I do not agree with what I interpret as your suggestion that
	 3DES (vs. DES) become the default encryption algorithm.  The
	 IAB memo on crypto policy does not strike me as mandating
	 such.  Moreover, in selecting any safeguard, one must balance
	 percieved threats against costs.

This is a crucial point.  I agree that 3DES is too expensive to be the
default transform.  I also agree that the IAB had no intention of mandating
such a move, and I was one of the authors of the statement.  On the
other hand, I didn't read John's note as suggesting it, either; rather
(and this may be based on prior conversations with him), he was suggesting
a mandatory-to-implement 3DES transform, so that people who want it will
have it.

John -- what did you mean?