Interoperability issue with curve25519

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Interoperability issue with curve25519

Hohwiller, Jörg

Hi everyone,

AFAIK in cryptography the idea is to standardize algorithms in a manner such that they are interoperable such that encryption, decryption, signing, and signature-verification produce the "same" results (except for nonces, etc.) no matter what platform/OS or programming language is used.

I am using Java with bouncycastle and want to sign and encrypt based on curve25519. If I got things right, curve25519 ist "just" a specification of an elliptic curve so it mainly impacts key management. For signing I would use ECDSA and for encryption ECIES. I hope this already makes sense so far. At least I was able to both encrypt/decrypt and sign/verify with this setup.

Now I tried to do the same with other existing solutions and figured out interoperability issues:

Digging the web I found that others have the same issues but there are no solving aswers:

https://crypto.stackexchange.com/questions/51703/how-to-convert-from-curve25519-33-byte-to-32-byte-representation

Regarding the given answer I also verified that the public key does not only differ in byte-ordering but seems to be something way more different.

FYI: As I went trough tons of pain figuring out how to deal with JCE, bouncycastle, limited strength in old JDK, nounces, and millions of other pitfalls I have started to create a library on top of all this to make things simpler for the rest of the world:

https://github.com/m-m-m/security/

https://github.com/m-m-m/security/blob/master/crypt/src/main/java/net/sf/mmm/security/api/key/asymmetric/SecurityAsymmetricKeyConfigCurve25519.java#L71

My actual goal is to write a java port implementation of a sustainable cryptocurrency based on freemoney and universal dividend to make the world a better place in the future :)

If you have any hints that could help me out I would be very pleased!

Thanks in advance

  Jörg

Reply | Threaded
Open this post in threaded view
|

RE: Interoperability issue with curve25519

Eckenfels. Bernd
Hello,

there are many different formats and standards to be compatible with, so you always need to consider that. On keys the getEncoding() normally returns ASN.1 of PKCS#8 structures, this is not what DJB describes in his paper.  In regards to ECPoint.getEncoding(true) the encoded form is defined by SEC1 and starts with a ECPointFormat byte: 

Field  Description
   ------ --------------------------------------------------------------
   B0     {02, 03, 04}, where 02 or 03 represent a compressed point (x
          only), while 04 represents a complete point (x,y)
   X      x coordinate of a point
   Y      y coordinate of a point, optional (present only for B0=04) So you can just strip the first byte if it is 0x02 or 0x03.

Not sure about the other details, but maybe this helps?
http://bouncycastle.org/wiki/display/JA1/Elliptic+Curve+Key+Pair+Generation+and+Key+Factories<a href="http://bouncycastle.org/wiki/display/JA1/Elliptic&#43;Curve&#43;Key&#43;Pair&#43;Generation&#43;and&#43;Key&#43;Factories" target="_blank">http://bouncycastle.org/wiki/display/JA1/Elliptic+Curve+Key+Pair+Generation+and+Key+Factories

Gruss
Bernd
--
http://www.seeburger.com

From: Hohwiller, Jörg [[hidden email]]
Sent: Friday, May 04, 2018 14:49
To: [hidden email]
Subject: [dev-crypto] Interoperability issue with curve25519

Hi everyone,

AFAIK in cryptography the idea is to standardize algorithms in a manner such that they are interoperable such that encryption, decryption, signing, and signature-verification produce the "same" results (except for nonces, etc.) no matter what platform/OS or programming language is used.

I am using Java with bouncycastle and want to sign and encrypt based on curve25519. If I got things right, curve25519 ist "just" a specification of an elliptic curve so it mainly impacts key management. For signing I would use ECDSA and for encryption ECIES. I hope this already makes sense so far. At least I was able to both encrypt/decrypt and sign/verify with this setup.

Now I tried to do the same with other existing solutions and figured out interoperability issues:

Digging the web I found that others have the same issues but there are no solving aswers:

https://crypto.stackexchange.com/questions/51703/how-to-convert-from-curve25519-33-byte-to-32-byte-representation

Regarding the given answer I also verified that the public key does not only differ in byte-ordering but seems to be something way more different.

FYI: As I went trough tons of pain figuring out how to deal with JCE, bouncycastle, limited strength in old JDK, nounces, and millions of other pitfalls I have started to create a library on top of all this to make things simpler for the rest of the world:

https://github.com/m-m-m/security/

https://github.com/m-m-m/security/blob/master/crypt/src/main/java/net/sf/mmm/security/api/key/asymmetric/SecurityAsymmetricKeyConfigCurve25519.java#L71

My actual goal is to write a java port implementation of a sustainable cryptocurrency based on freemoney and universal dividend to make the world a better place in the future :)

If you have any hints that could help me out I would be very pleased!

Thanks in advance

  Jörg






     


SEEBURGER AG   Vorstand/SEEBURGER Executive Board:
Sitz der Gesellschaft/Registered Office:   Axel Haas, Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias Feßenbecker
Edisonstr. 1  
D-75015 Bretten Vorsitzende des Aufsichtsrats/Chairperson of the SEEBURGER Supervisory Board:
Tel.: 07252 / 96 - 0 Prof. Dr. Simone Zeuchner
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de Registergericht/Commercial Register:
e-mail: [hidden email] HRB 240708 Mannheim


Dieses E-Mail ist nur für den Empfänger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungsäußerung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese E-Mail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anhänge auf Viren zu prüfen.

This email is intended only for the recipient(s) to whom it is addressed. This email may contain confidential material that may be protected by professional secrecy. Any fact or opinion contained, or expression of the material herein, does not necessarily reflect that of SEEBURGER AG. If you are not the addressee or if you have received this email in error, any use, publication or distribution including forwarding, copying or printing is strictly prohibited. Neither SEEBURGER AG, nor the sender (Eckenfels. Bernd) accept liability for viruses; it is your responsibility to check this email and its attachments for viruses.

Reply | Threaded
Open this post in threaded view
|

Re: Interoperability issue with curve25519

David Hook-3
In reply to this post by Hohwiller, Jörg

You'd expect the ECDSA signatures to vary in length as they involve random numbers and the encoding is an actually a DER SEQUENCE containing two INTEGER objects. As these are signed the byte length will vary - if the top bit of one of the signature values is 1 then a sign byte will be added. I would actually be worried if two different implementations produced identical signatures - the real question is whether both implementations can verify each other's signatures.

Concerning the keys being 32 bytes - that encoding would not be possible using either PKCS#1 or PKCS#8. I suspect they are talking about a raw encoding there.

Regards,

David

On 04/05/18 22:49, Hohwiller, Jörg wrote:

Hi everyone,

AFAIK in cryptography the idea is to standardize algorithms in a manner such that they are interoperable such that encryption, decryption, signing, and signature-verification produce the "same" results (except for nonces, etc.) no matter what platform/OS or programming language is used.

I am using Java with bouncycastle and want to sign and encrypt based on curve25519. If I got things right, curve25519 ist "just" a specification of an elliptic curve so it mainly impacts key management. For signing I would use ECDSA and for encryption ECIES. I hope this already makes sense so far. At least I was able to both encrypt/decrypt and sign/verify with this setup.

Now I tried to do the same with other existing solutions and figured out interoperability issues:

Digging the web I found that others have the same issues but there are no solving aswers:

https://crypto.stackexchange.com/questions/51703/how-to-convert-from-curve25519-33-byte-to-32-byte-representation

Regarding the given answer I also verified that the public key does not only differ in byte-ordering but seems to be something way more different.

FYI: As I went trough tons of pain figuring out how to deal with JCE, bouncycastle, limited strength in old JDK, nounces, and millions of other pitfalls I have started to create a library on top of all this to make things simpler for the rest of the world:

https://github.com/m-m-m/security/

https://github.com/m-m-m/security/blob/master/crypt/src/main/java/net/sf/mmm/security/api/key/asymmetric/SecurityAsymmetricKeyConfigCurve25519.java#L71

My actual goal is to write a java port implementation of a sustainable cryptocurrency based on freemoney and universal dividend to make the world a better place in the future :)

If you have any hints that could help me out I would be very pleased!

Thanks in advance

  Jörg