Re: [Cfrg] RE: Where's the beef?

Jim Hughes <> Fri, 30 August 2002 20:34 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id QAA04690 for <>; Fri, 30 Aug 2002 16:34:49 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id g7UKZt523076 for; Fri, 30 Aug 2002 16:35:55 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g7UKZto23073 for <>; Fri, 30 Aug 2002 16:35:55 -0400
Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id QAA04678; Fri, 30 Aug 2002 16:34:18 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id g7UKZCo23063; Fri, 30 Aug 2002 16:35:12 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id g7UKY3o23027 for <>; Fri, 30 Aug 2002 16:34:03 -0400
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA04608 for <>; Fri, 30 Aug 2002 16:32:24 -0400 (EDT)
Received: from ( []) by (8.9.3+Sun/8.9.3) with ESMTP id PAA02598; Fri, 30 Aug 2002 15:25:34 -0500 (CDT)
Received: from ( []) by (8.9.3/8.9.3) with ESMTP id PAA15836; Fri, 30 Aug 2002 15:25:32 -0500
Received: (from hughes@localhost) by (8.11.6/8.11.6) id g7ULKJj09169; Fri, 30 Aug 2002 16:20:19 -0500
X-Authentication-Warning: hughes set sender to using -f
Subject: Re: [Cfrg] RE: Where's the beef?
From: Jim Hughes <>
To: Alex Alten <>
Cc: "David A. Mcgrew" <>,, Ran Canetti <>
In-Reply-To: <>
References: <>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.8
Date: 30 Aug 2002 16:20:19 -0500
Message-Id: <1030742419.11392.12660.camel@jimsguin>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Crypto Forum Research Group <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

au contraire, mon ami. 

The best way to get the best minds to look at the problem for free is to
write a bad standard. 

The fame for breaking a standard (ala RC-4 and thus WEP, A5 and thus
GSM, CBC padding and thus SSL, IPSEC and WTLS) is very seductive to the
people that do this for a living. It is also very embarrassing and
humbling experience that I do not want to be a party to.  

What has done is to pose a specific problem to the
crypto community so that the real cryptographers look at it. We have
been successful with a call for algorithms at getting several of
the top names in crypto modes to look at the problem for free, and we
also hope that they will come and present at a large workshop We hope to standardize at
least one of the solutions.

By stating the problem in more cryptographic terms so that an algorithm
can be found (if it exists) or built, and by casting a wide net, I
believe will result in a better outcome than the usual committee
approach. is nice and it will bring added light on the process and
help a group be sure they are not making a real bonehead move, but a
review by this list not be enough to have caught the RC-4, A5 or CBC
weaknesses. The review may have resulted in opinions that "I would not
have done it this way" but I doubt that in these cases that these
opinions would have swayed the committee away from their "decision". I
doubt if paying people to do the research will provide anything more
than similar opinions and committees with similar final (non) decisions.

I believe a better way is to try to educate the committees on how to
engage the crypto community before they get their feet cemented in a
particular solution, and if we can do this, then this will be a valuable



On Fri, 2002-08-30 at 13:50, Alex Alten wrote:
> At 10:58 AM 8/30/2002 -0700, David A. Mcgrew wrote:
> >> Do you have a budget to do serious stuff?
> >
> >What do you have in mind?  Is there something that you'd like to see
> >discussed or reviewed?
> >
> You side-stepped my budget question.  So I assume no money is available.
> This is a pity, because the best minds in the crypto world will not work
> for free, unlike the usual university or corporate lab network
> programmer
> in an IETF WG.  This will make it difficult to produce anything useful
> here.  As a practical matter we will need to back up our RFC's with
> outside analysis.  This can be costly (although I suppose we would get
> discounts).
> Good luck (raising cash),
> - Alex
> --
> Alex Alten
> _______________________________________________
> Cfrg mailing list
Cfrg mailing list