[EXPERIMENTAL-PATCH] Curve25519 encryption support (updated)

Christian Grothoff grothoff at gnunet.org
Fri Jul 24 08:38:39 CEST 2015

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.

More information about the Gcrypt-devel mailing list