Re: [TLS] [Cfrg] Citing specs in specs

[Paul Lambert <[e-mail]>]

On 3/3/14, 2:52 PM, "Jon Callas" <[e-mail]> wrote:

>On Mar 2, 2014, at 3:40 PM, Paul Lambert <[e-mail]> wrote:
>
>> Implementations are possible by using the readily available open source
>> implementation.  This is a good thing, but it is also desirable
>> to have a unambiguous description of the algorithms that is not
>> a C code file.  This is why we write RFCs...
>
>It's hard to disagree with this, in a similar way that it's hard to
>disagree with the idea of peace on earth, living at one with nature, etc.
>
>But in practice, code needs to be in a computer language rather than
>English and I've seen (and been involved with) a document that started
>with rough consensus and running code, translated that into English, and
>the English was (and is) devilishly hard to compile back into C.
Yes - I¹e seen the same problem.  English is not a concise or clear way to
document an algorithm.

HAC is pretty clear and is a decent example of cryptographic algorithm
descriptions (http://cacr.uwaterloo.ca/hac/about/chap8.pdf), but still
uses a mix of math notation and english text.
>
>Portably implemented algorithms are hard to do in any computer language.
>They're harder to do in words. I don't see how you're going to get an
>unambiguous description of the language in anything but a computer
>language. It doesn't have to be C, it could be Python, Ruby, or Algol-58
>(which I mention because it was originally designed as an algorithmic
>description language). English is a suboptimal implementation language.

Yes, exactly!   'Readable code¹ would be a very good way to provide an
algorithm description.  Why bother with pseudo code when a executable
syntax could be used.   I submitted earlier on this list some Python code
fragments as examples of this approach.  Python allows operator
overloading, so it can provide some very readable ECC algorithm
descriptions.

Paul




>
>	Jon
>