Re: [Cfrg] What crypto algorithm is referenced most in RFCs?

Simon Josefsson <> Wed, 15 June 2011 07:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97EB711E80C5 for <>; Wed, 15 Jun 2011 00:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BkfxZqWYfvmF for <>; Wed, 15 Jun 2011 00:32:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7455211E8074 for <>; Wed, 15 Jun 2011 00:31:59 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5F7VX0c025721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 15 Jun 2011 09:31:36 +0200
From: Simon Josefsson <>
To: Jon Callas <>
References: <> <> <> <>
OpenPGP: id=B565716F; url=
Date: Wed, 15 Jun 2011 09:31:33 +0200
In-Reply-To: <> (Jon Callas's message of "Tue, 14 Jun 2011 16:59:27 -0700")
Message-ID: <>
User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97 at yxa-v
X-Virus-Status: Clean
Subject: Re: [Cfrg] What crypto algorithm is referenced most in RFCs?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jun 2011 07:32:01 -0000

Jon Callas <> writes:

> I disagree. What would be helpful would be to identify
> *implementations* that should mend their ways. The map is not the
> territory. The RFCs are the maps; the implementations are the
> territories. If you change the map so that it represents an idealized
> reality, it's not the same thing as a fixed reality. I think reality
> is better than this survey of maps indicates.


Use of DES/RC2/MD4 is still not uncommon.

> If you want to have a positive effect on the world with the minimum
> windmill-tilting, go find the RFCs that do not have reasonable
> extensions. Continuing my example, something that is using (e.g.) bare
> MD5 with no option for SHA2. Update that RFC to have SHA2 as a MAY,
> and then poke the implementers to migrate on their own. I can think of
> a few things I might pursue (CRAM-MD5 springs to mind), but focus your
> righteous anger on the implementations that are screwing up and then
> on the implementations that are doing something half-assed because the
> only option they have is to do something half-assed. Write the new RFC
> for them with something full-assed.

For CRAM-MD5 to fall, I think you need to show that there are practical
attacks on HMAC-MD5.  As far as I recall this hasn't been done yet.

I'm more concerned with DIGEST-MD5.  I'm not sure significant number of
people in the crypto community bothers to study it.  However DIGEST-MD5
is widely implemented and used.

Fortunately, we have SCRAM to replace them both. :-)