[Cryptech Tech] Regarding Curve25519 and IETF

[Bernd Paysan]

Am Mittwoch, 17. Dezember 2014, 09:51:01 schrieb Peter Schwabe:
> Bernd Paysan <bernd at net2o.de> wrote:
> 
> Good morning,
> 
> I just read the message on Curve25519 and Ed25519 and thought that I
> throw in my 2 cents.
> 
> > So the thing I would propose for standardization is to use Ed25519
> > both for
> > signature and for ECDH, having only one form for both purposes is a
> > good idea
> > - you don't have to implement the basics twice, and if you like to,
> > you can
> > use your pubkey both for signing and encryption.
> 
> Using the same key pair for signing and for encryption is not
> necessarily secure. Dan, Tanja (both in CC), and I are planning to
> investigate this in more detail and come up with a solution that
> supports one key for both encryption and signing in a secure way. You
> might want to wait until we're done with this.

Ok, I'll wait and see what you come up with.

The way I understand it is that you have a "hard" operation to go from pubkey 
back to secret key ("hard" in the sense of "best known attack is O(2^n/2) for 
n bit keys"), and the effort is roughly the same for both curves (with a 
slighlty smaller constant for Ed25519), and that the identity pk1*sk2 = 
pk2*sk1 for DHE holds.  pk2*sk1 is not transmitted, it's only the shared 
secret to initialize the symmetric crypto with (plus IV), so even if crafting 
pk2 in such a way (insecure twist, if there was one, or such) that pk2*sk1 
might expose something, doesn't help the attacker.  Using Ed25519 needs point 
decompression to do that calculation, but that operation is relatively cheap.

The DHE handshake does not reveal anything a signature would not reveal, too, 
because all you do is send your pubkey - and any attacker could do pk2*sk1 on 
a received pubkey, so this operation alone can't be harmful.

The only thing I needed to add to Ed25519 was a constant-time scalar product, 
which has a 10-20% overhead over the variable-time scalar product used for 
signatures.

> Well, only if you don't re-use ephemeral keys for a short time

I don't want to, because a re-used ephemeral key can be used to track your 
identity, even if you use onion routing to hide your source address.  This is 
from the initiator's point of view, the responder can reuse his ephemeral key 
for a short time.  But when I make that kind of thing, I better use the same 
code for initiator and responder...

> (for a
> discussion, see [1, Appendix D]. Curve25519 is still conceptually easier
> (no decompression needed etc.) and the overhead of implementing both is
> negligible because the field arithmetic is shared.

Yes, but it still requires exchanging two keys.  The big advantage of 
Curve25519 (including Edwards form) is that the pubkeys are so small that you 
e.g. can print a pubkey e.g. on your business card (just 40 characters with 
base85).

> Maybe Dan wants to comment here, but I have never heard him say that you
> should scrap Curve25519 and just use Ed25519 for DH.

What about the new, longer curves?  They have only Edwards form.  I see the 
problem with legacy in Curve25519 - a number of protocols already use it, and 
therefore it can't be changed.  I need Ed25519, because I need signing 
capabilities, and I want to have a single pubkey.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.cryptech.is/archives/tech/attachments/20141217/994f7a86/attachment.sig>