Re: [Cfrg] ECC mod 8^91+5

[Dan Brown <[e-mail]>]

Hi Stephen & CFRG,

I updated the Internet Draft
https://datatracker.ietf.org/doc/draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5/
including an effort to address some of your concerns about "preferred" curves. 
For example, the 2nd sentence of the abstract now says:

"This curve is recommended for cryptographic use in a strongest-link 
combination with dissimilar elliptic curves (e.g. NIST P-256, Curve25519, 
extension-field curves, etc.)  as a defense in depth against an unlikely, 
unforeseen attack on otherwise preferred elliptic curves."

Although the previous version had discussed some of these issues, it did so 
much less prominently and (even) less clearly, way back in the security 
considerations - probably too far back in the document for all but the most 
ECC-avid readers.

My wish is that the revised version does not aggravate the confusion around 
ECC.

Alas, I seem to have knack for confusing.  Case in point: the draft's title 
specifies most details of the curve via a formula, making the point that, as 
far as ECC goes, this is a rather simple curve.  For some readers, it would 
make the exact opposite point: a formula looks even more complicated than a 
name (but these are not the intended audience anyway).

Best regards,
Dan


-----Original Message-----
From: Cfrg [mailto:[e-mail]] On Behalf Of Stephen Farrell
Sent: Saturday, October 21, 2017 6:19 PM
To: Paterson, Kenny <[e-mail]>; [e-mail]
Subject: Re: [Cfrg] ECC mod 8^91+5


I'd have no objection to CFRG producing an RFC for this, if there is support. 
I don't support doing so myself, but if the RG do go ahead with that I would 
really hope that the resulting RFC is clearly cast as not being as "preferred" 
as the curves already documented.

If additional curves were to be documented by CFRG without such distinctions, 
then I would object to that on the grounds that the inevitable confusion 
arising would devalue CFRG for the IETF at least.

So, while I'm not qualified wrt the crypt details myself, I'd prefer to not 
see this adopted. If it is adopted, I'd strongly argue that it be flagged as 
being less preferred vs. the currently documented curves.

S.

On 21/10/17 18:28, Paterson, Kenny wrote:
> Dear CFRG,
>
> Dan has specifically asked for CFRG adoption of his draft. Any support
> for this from the group?
>
> Cheers,
>
> Kenny
>
> On 16/10/2017 16:08, "Cfrg on behalf of Dan Brown"
> <[e-mail] on behalf of [e-mail]> wrote:
>
>> Hi CFRG,
>>
>> For those still interested, I've uploaded an Internet-Draft on ECC on
>> 2y^2=x^3+x/GF(8^91+5):
>>
>> https://tools.ietf.org/html/draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-
>> 5-00
>> https://datatracker.ietf.org/doc/draft-brown-ec-2y2-x3-x-mod-8-to-91-
>> plus-
>> 5/
>>
>> It is very much a work-in-progress, maybe more so than a typical I-D.
>>
>> If I have incorporated some CFRG list comments into the draft, then I
>> hope to properly acknowledge in the next update.
>>
>> The main point of this curve is to use it in a system of
>> multiply-applied diverse crypto, where its security features (special
>> CM curve, minimal room for trapdoor) could complement those of other
>> crypto algorithms (including PQC and other ECC algorithms).  Using
>> this variant of ECC as the sole (PK) crypto would be risky (due to
>> lack of track-record/aegis/scrutiny/etc.).
>>
>> If the IETF and CFRG intend to generally pursue and encourage support
>> of multiply-applied diverse crypto, at least where it is affordable
>> (in the higher user-to-user network layers?), then I would ask the
>> CFRG to consider this I-D as a work item.  Otherwise, maybe this I-D
>> should stay on the individual submission stream.
>>
>> Best regards,
>>
>> Dan
>>
>> -----Original Message-----
>> From: Dan Brown
>> Sent: Tuesday, May 16, 2017 1:36 PM
>> To: [e-mail]
>> Subject: ECC mod 8^91+5
>>
>> Hi all,
>>
>> I'm considering writing an I-D on doing ECC over the field of size
>>   8^91+5    (=2^273+5),
>> because it:
>> ...
>>
>> For ECC with this field, I am also considering the special curve
>>   2y^2=x^3+x,
>> because it:
>> ...
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>