Re: [Cfrg] wrt providing guidance to implementors (was: Safecurves v Brainpool / Rigid v Pseudorandom)

=JeffH <Jeff.Hodges@KingsMountain.com> Wed, 15 January 2014 22:14 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05EA1AE266 for <cfrg@ietfa.amsl.com>; Wed, 15 Jan 2014 14:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.516
X-Spam-Level: *
X-Spam-Status: No, score=1.516 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqa1_IBXqopr for <cfrg@ietfa.amsl.com>; Wed, 15 Jan 2014 14:14:30 -0800 (PST)
Received: from oproxy1-pub.mail.unifiedlayer.com (oproxy1-pub.mail.unifiedlayer.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 9D67E1AE237 for <cfrg@irtf.org>; Wed, 15 Jan 2014 14:14:30 -0800 (PST)
Received: (qmail 13705 invoked by uid 0); 15 Jan 2014 22:14:18 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy20.mail.unifiedlayer.com with SMTP; 15 Jan 2014 22:14:18 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=DxDcaYVzuCswF4ShGJQTpbsXjj5vPT7iM/nsohlp5i8=; b=8k/otXMQYZgEpYTkF2oMhDFkYiERF2HJatlJn+aNGCYfNpDXa46fGkIuVA71npQR+1IQwDOBOOIcMXupnmHHCaIjRvP+IMfJirvLJD08Tm9T5OjGq+H7U9KIaZc+OpiJ;
Received: from [216.113.168.128] (port=10133 helo=[10.244.137.220]) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1W3Yj4-0005ac-RV for cfrg@irtf.org; Wed, 15 Jan 2014 15:14:18 -0700
Message-ID: <52D70851.4000805@KingsMountain.com>
Date: Wed, 15 Jan 2014 14:14:41 -0800
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130330 Thunderbird/17.0.5
MIME-Version: 1.0
To: IRTF Crypto Forum Research Group <cfrg@irtf.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com}
Subject: Re: [Cfrg] wrt providing guidance to implementors (was: Safecurves v Brainpool / Rigid v Pseudorandom)
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 22:14:32 -0000

Watson Ladd wondered..
 >
 > And what does it say
 > about our implementors that they do not know the basics of the algorithms
 > they are asked to implement?

unfortunately, there are many examples of implementors not exactly 
understanding the stuff they're implementing and/or lacking diligence in 
ensuring all the myriad parameters are set correctly & meaningfully, etc., etc.

Here's a recent survey wrt ECC in particular..

Bos, Joppe W., et al. "Elliptic Curve Cryptography in Practice." Microsoft 
Research. November (2013).
http://cryptome.org/2013/11/ecc-practice.pdf


Thus, "implementation advice/guidance" is often an important part of 
specifications.

HTH,

=JeffH

ps: there's also this classic bare-fisted rant..

Mark Pilgrim: Why Specs Matter
<http://web.archive.org/web/20051016203842/http://diveintomark.org/archives/2004/08/16/specs>

[ unfortunately, diveintomark.org itself is AWOL:
<https://en.wikipedia.org/wiki/Mark_Pilgrim#.22Disappearance.22_from_the_Internet> 
]


conclusion (reprinted without permission, sorry):

Why specs matter

If your spec isn’t good enough, morons have no chance of ever getting things
right. For everyone who complains that their software is broken, there will
be two assholes who claim that it’s not. The spec, whose primary purpose is
to arbitrate disputes between morons and assholes, will fail to resolve
anything, and the arguments will smolder for years.

If your spec is good enough, morons have a fighting chance of getting things
right the second time around, without being besieged by assholes.
Meanwhile, the assholes who have nothing better to do than look for
loopholes won’t find any, and they’ll eventually get bored and wanderoff in
search of someone else to harass.


---
end