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

Joachim Strömbergson <> Tue, 14 June 2011 06:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6BE3811E8120 for <>; Mon, 13 Jun 2011 23:16:17 -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 jXIiRUY5CgIv for <>; Mon, 13 Jun 2011 23:16:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7F6D211E8088 for <>; Mon, 13 Jun 2011 23:16:15 -0700 (PDT)
Received: from ([] helo=snabbis.local) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1QWMv8-000659-6k for; Tue, 14 Jun 2011 08:16:14 +0200
Message-ID: <>
Date: Tue, 14 Jun 2011 08:16:13 +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: Tue, 14 Jun 2011 06:16:17 -0000

Hash: SHA1


On 2011:06:13 16:04, David McGrew wrote:
> That last page can be used to answer the question in the subject line. 
> (Hint: it is not something most of us probably recommend anymore.)

I was amazed that there were so many of those drafts that are in
standards track. Drafts in informational track describing uses of
insecure algorithms is imho ok, since they document a practice.
Similarly, RFCs are a done deal and if they are a standard RFC must be
replaced by newer RFCs to fix security issues.

But in 2011 writing a draft for standards track that includes known
insecure, broken algorithms?

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?

- -- 
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 -