|
|
|
On 07/13/2018 04:50 PM, Christian Grothoff wrote:
|
|
> On 07/13/2018 06:39 PM, Bernd Fix wrote:
|
|
>> This constraint of course make things trickier, because that means we
|
|
>> are stuck in using Ed25519 for ECDHE. A possible solution (again: not
|
|
>> for GNUnet itself, but for implementators in general) for using Ed25519
|
|
>> points with ECDHE is to use the bijective mapping between Ed25519 and
|
|
>> Curve25519 and to do the ECDHE on Curve25519. Not nice probably, but
|
|
>> that could work.
|
|
>
|
|
> Well, there is another possibility: simply have *two* versions of
|
|
> ECDHE/X25519: one for Taler where we mix it with EdDSA, and another one
|
|
> for GNUnet core/cadet KX where we do not rely on this property.
|
|
|
|
And maybe even a third one: I stumbled across an approach to use
|
|
Curve25519 keypairs for both ECDH and Ed25519 signatures
|
|
[https://moderncrypto.org/mail-archive/curves/2014/000293.html].
|
|
|
|
Would that be feasible also for Taler? Since Taler (afaik) relies on
|
|
some GNUnet mechanisms, it seems preferable not to introduce YACS (Yet
|
|
Another Crypto Scheme)...
|
|
|