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

[=JeffH <[e-mail]>]

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