[EXPERIMENTAL-PATCH] Curve25519 encryption support (updated)

[Christian Grothoff]

Why have a flag for the sane/safe behaviour? If we need a flag at all,
shouldn't we have it for the unsafe behaviour? (and then we can just
call it 'unsafe', to be appropriately discouraging).  AFAIK encryption
support is kind-of new anyway, so hopefully this isn't needed to avoid
breaking backwards-compatibility with anything that has been deployed...

On 07/24/2015 08:32 AM, NIIBE Yutaka wrote:
> On 07/23/2015 09:32 PM, Werner Koch wrote:
>> On Thu, 23 Jul 2015 10:02, gniibe at fsij.org said:
>>
>>> So, its meaning is sec-is-multiplied-by-cofactor-and-msb-set (not mont
>>> or x-only, which is defined by curve's model or compression).
>>>
>>> I don't have good naming for the flag though.
>>
>> "djb" :-)
> 
> It is good for us. :-)  It would require some more explanation
> for other people.
> 
>> Anyone else with a suggestion for the name of such a flag?
> 
> From poor vocabulary of non-native speaker,
> 
>     trim, rational, legitimate, validated, solid,
> 
> come up.
> 
> I think that the practice makes much sense because it encourages
> constant time implementation.  I wonder why it wasn't common for
> the standardization of ECC before safe curves.
> 
> 
> How about "advance"?  In some sense, a secret key with this flag is
> like a ticket sold in advance; For both sides (buy & sell), it
> eliminates a possibility of failures (of payment).
> 
> When we see the flag, it means that it's advanced ECC with safe curve.
> 
> My point is: It would be good it has better connotation.
>