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

Joachim Strömbergson <> Wed, 15 June 2011 07:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6CA3A11E80DD for <>; Wed, 15 Jun 2011 00:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9rgaT0+ZSh3x for <>; Wed, 15 Jun 2011 00:42:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 23BAE11E8074 for <>; Wed, 15 Jun 2011 00:42:53 -0700 (PDT)
Received: from ([] helo=snabbis.local) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1QWkkW-0003nl-Fi for; Wed, 15 Jun 2011 09:42:52 +0200
Message-ID: <>
Date: Wed, 15 Jun 2011 09:42:51 +0200
From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= <>
Organization: Kryptologik
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
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:42:55 -0000

Hash: SHA1


On 2011:06:15 1:59, Jon Callas wrote:
>>> Would it be fruitful to browse the list try and identify the
>>> most pressing cases and try to convince the authors that they
>>> should mend their ways?
>> Actually, it would.
> 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.

Jon, I'm sorry for not being more clear. What I was implicitly referring
to was the lists of active drafts, not RFCs. I agree that for RFCs it is
more important to look at implementations.

But the drafts has not yet become the map. Fixing errors in the map to
be before it is printed isn't that better than waiting until it has been
printed and in use?

We basically have two different problems:
(1) Help implemementations to migrate from algorithms we don't trust
anymore to the algorithms we trust, algorithms specified in updated
versions of the map.

(2) Help map developers avoid specifying use of the bad algorithms so
that new implementations don't end up using bad algorithms in the first

More understandable? And agreeable?

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
Kryptoblog - IT-säkerhet på svenska
Version: GnuPG v1.4.11 (Darwin)
Comment: Using GnuPG with Mozilla -