

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 signatureverification 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/howtoconvertfromcurve2551933byteto32byterepresentation
Regarding the given answer I also verified that the public key
does not only differ in byteordering 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/mmm/security/
https://github.com/mmm/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


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+Curve+Key+Pair+Generation+and+Key+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: [devcrypto] 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 signatureverification 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/howtoconvertfromcurve2551933byteto32byterepresentation
Regarding the given answer I also verified that the public key does not only differ in byteordering 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/mmm/security/
https://github.com/mmm/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 


D75015 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: 
email: [hidden email] 

HRB 240708 Mannheim 
Dieses EMail 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 EMail irrtümlich erhalten und jegliche Verwendung, Veröffentlichung, Weiterleitung, Abschrift
oder jeglicher Druck dieser EMail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für Viren; es obliegt Ihrer Verantwortung, die EMail 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.


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 signatureverification
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/howtoconvertfromcurve2551933byteto32byterepresentation
Regarding the given answer I also verified that the public
key does not only differ in byteordering 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/mmm/security/
https://github.com/mmm/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

