Hello, I'm wondering how to use Elliptic-Curve-Cryptography preferrably with Ed25519 instead of RSA to encrypt some data (a random symmetric key, actually). Using RSA, I could -- when using the JCA -- instantiate a Cipher with a cipher-transformation like e.g. "RSA/ECB/OAEPWithSHA-256AndMGF1Padding". In order to generate an RSA-key, I can use the KeyPairGenerator with the algorithm "RSA". But I didn't find a way to do this with ECC. I analysed the BouncyCastle-sources a bit and did some experiments -- and for the key-generation, the following code works: KeyPairGenerator keyPairGenerator =
KeyPairGenerator.getInstance(EdDSAParameterSpec.Ed25519,
BouncyCastleProvider.PROVIDER_NAME); But I didn't find any way to obtain a cipher, yet. I checked org.bouncycastle.jce.provider.BouncyCastleProvider.ASYMMETRIC_CIPHERS and there is "EdEC". But trying Cipher.getInstance("EdEC/ECB/OAEPWithSHA-256AndMGF1Padding", BouncyCastleProvider.PROVIDER_NAME); does not work. Neither does "Ed25519" instead of "EdEC". I'm not sure, whether this padding makes even sense in this context, but if the padding was wrong/incompatible, the error-message should IMHO be different (or is this assumption wrong)? Or is there no JCE-integration? If so, how could I use ECC with Ed25519 using BC-internal API? For RSA, there's the class RSAEngine (just like for AES, Twofish etc.), but I didn't find any EdECEngine or Ed25519Engine. Best regards, Marco :-) signature.asc (849 bytes) Download Attachment |
Ed25519 is specifically for signing. For anything involving encryption you want to be using X25519 or X448 if you're trying to use Edwards Curves. Encryption using EC curves is different to RSA, I would recommend reading up on these differences before going any further, it's not overly complicated, just requires a slightly different mindset. Regards, David On 24/9/20 1:59 am, Marco Nguitragool wrote: > > Hello, > > I'm wondering how to use Elliptic-Curve-Cryptography preferrably with > Ed25519 instead of RSA to encrypt some data (a random symmetric key, > actually). > > Using RSA, I could -- when using the JCA -- instantiate a Cipher with > a cipher-transformation like e.g. > "RSA/ECB/OAEPWithSHA-256AndMGF1Padding". In order to generate an > RSA-key, I can use the KeyPairGenerator with the algorithm "RSA". > > But I didn't find a way to do this with ECC. I analysed the > BouncyCastle-sources a bit and did some experiments -- and for the > key-generation, the following code works: > > KeyPairGenerator keyPairGenerator = > KeyPairGenerator.getInstance(EdDSAParameterSpec.Ed25519, > BouncyCastleProvider.PROVIDER_NAME); > AlgorithmParameterSpec keyGenParam = new > EdDSAParameterSpec(EdDSAParameterSpec.Ed25519); > keyPairGenerator.initialize(keyGenParam, random); > keyPairGenerator.generateKeyPair(); > > But I didn't find any way to obtain a cipher, yet. I checked > > org.bouncycastle.jce.provider.BouncyCastleProvider.ASYMMETRIC_CIPHERS > > and there is "EdEC". But trying > > Cipher.getInstance("EdEC/ECB/OAEPWithSHA-256AndMGF1Padding", > BouncyCastleProvider.PROVIDER_NAME); > > does not work. Neither does "Ed25519" instead of "EdEC". > > I'm not sure, whether this padding makes even sense in this context, > but if the padding was wrong/incompatible, the error-message should > IMHO be different (or is this assumption wrong)? > > Or is there no JCE-integration? If so, how could I use ECC with > Ed25519 using BC-internal API? For RSA, there's the class RSAEngine > (just like for AES, Twofish etc.), but I didn't find any EdECEngine or > Ed25519Engine. > > Best regards, > > Marco :-) > |
Hi David,
thanks a lot! I'm going to read about it and give X25519 a try. I thought / hoped that the JCA's Cipher-API can be used with ECC, too. Otherwise I'd have to refactor the entire application :-( Hmmm... I already started reading and X25519 is a Diffie-Hellman-function. So it does actually too much, already, if I understand it correctly. The code which currently uses RSA -- and should be switched to ECC -- encrypts a random ephemeral key (used for symmetric crypto). Well, I think I need to do read more about this topic... Best regards, Marco :-) Am 25.09.20 um 04:56 schrieb David Hook: > Ed25519 is specifically for signing. > > For anything involving encryption you want to be using X25519 or X448 if > you're trying to use Edwards Curves. Encryption using EC curves is > different to RSA, I would recommend reading up on these differences > before going any further, it's not overly complicated, just requires a > slightly different mindset. > > Regards, > > David > > On 24/9/20 1:59 am, Marco Nguitragool wrote: >> Hello, >> >> I'm wondering how to use Elliptic-Curve-Cryptography preferrably with >> Ed25519 instead of RSA to encrypt some data (a random symmetric key, >> actually). >> >> Using RSA, I could -- when using the JCA -- instantiate a Cipher with >> a cipher-transformation like e.g. >> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding". In order to generate an >> RSA-key, I can use the KeyPairGenerator with the algorithm "RSA". >> >> But I didn't find a way to do this with ECC. I analysed the >> BouncyCastle-sources a bit and did some experiments -- and for the >> key-generation, the following code works: >> >> KeyPairGenerator keyPairGenerator = >> KeyPairGenerator.getInstance(EdDSAParameterSpec.Ed25519, >> BouncyCastleProvider.PROVIDER_NAME); >> AlgorithmParameterSpec keyGenParam = new >> EdDSAParameterSpec(EdDSAParameterSpec.Ed25519); >> keyPairGenerator.initialize(keyGenParam, random); >> keyPairGenerator.generateKeyPair(); >> >> But I didn't find any way to obtain a cipher, yet. I checked >> >> org.bouncycastle.jce.provider.BouncyCastleProvider.ASYMMETRIC_CIPHERS >> >> and there is "EdEC". But trying >> >> Cipher.getInstance("EdEC/ECB/OAEPWithSHA-256AndMGF1Padding", >> BouncyCastleProvider.PROVIDER_NAME); >> >> does not work. Neither does "Ed25519" instead of "EdEC". >> >> I'm not sure, whether this padding makes even sense in this context, >> but if the padding was wrong/incompatible, the error-message should >> IMHO be different (or is this assumption wrong)? >> >> Or is there no JCE-integration? If so, how could I use ECC with >> Ed25519 using BC-internal API? For RSA, there's the class RSAEngine >> (just like for AES, Twofish etc.), but I didn't find any EdECEngine or >> Ed25519Engine. >> >> Best regards, >> >> Marco :-) |
Hello Marco,
using a key agreement for EC encryption is quite normal, you should not deviate from this. If you need to use key transport instead (encrypt your existing session key), then you can use the X25519 key agreement to get the ephemeral key and use that one to wrap your existing session key. This is for example used for S/Mime, as far as I remeber. S/Mime uses ECMQV Key agreement. Gruss Bernd -----Ursprüngliche Nachricht----- Von: Marco Nguitragool <[hidden email]> Gesendet: Dienstag, 29. September 2020 04:15 An: [hidden email] Betreff: Re: [dev-crypto] EdEC / Ed25519 Cipher? Hi David, thanks a lot! I'm going to read about it and give X25519 a try. I thought / hoped that the JCA's Cipher-API can be used with ECC, too. Otherwise I'd have to refactor the entire application :-( Hmmm... I already started reading and X25519 is a Diffie-Hellman-function. So it does actually too much, already, if I understand it correctly. The code which currently uses RSA -- and should be switched to ECC -- encrypts a random ephemeral key (used for symmetric crypto). Well, I think I need to do read more about this topic... Best regards, Marco :-) Am 25.09.20 um 04:56 schrieb David Hook: > Ed25519 is specifically for signing. > > For anything involving encryption you want to be using X25519 or X448 > if you're trying to use Edwards Curves. Encryption using EC curves is > different to RSA, I would recommend reading up on these differences > before going any further, it's not overly complicated, just requires a > slightly different mindset. > > Regards, > > David > > On 24/9/20 1:59 am, Marco Nguitragool wrote: >> Hello, >> >> I'm wondering how to use Elliptic-Curve-Cryptography preferrably with >> Ed25519 instead of RSA to encrypt some data (a random symmetric key, >> actually). >> >> Using RSA, I could -- when using the JCA -- instantiate a Cipher with >> a cipher-transformation like e.g. >> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding". In order to generate an >> RSA-key, I can use the KeyPairGenerator with the algorithm "RSA". >> >> But I didn't find a way to do this with ECC. I analysed the >> BouncyCastle-sources a bit and did some experiments -- and for the >> key-generation, the following code works: >> >> KeyPairGenerator keyPairGenerator = >> KeyPairGenerator.getInstance(EdDSAParameterSpec.Ed25519, >> BouncyCastleProvider.PROVIDER_NAME); >> AlgorithmParameterSpec keyGenParam = new >> EdDSAParameterSpec(EdDSAParameterSpec.Ed25519); >> keyPairGenerator.initialize(keyGenParam, random); >> keyPairGenerator.generateKeyPair(); >> >> But I didn't find any way to obtain a cipher, yet. I checked >> >> >> org.bouncycastle.jce.provider.BouncyCastleProvider.ASYMMETRIC_CIPHERS >> >> and there is "EdEC". But trying >> >> Cipher.getInstance("EdEC/ECB/OAEPWithSHA-256AndMGF1Padding", >> BouncyCastleProvider.PROVIDER_NAME); >> >> does not work. Neither does "Ed25519" instead of "EdEC". >> >> I'm not sure, whether this padding makes even sense in this context, >> but if the padding was wrong/incompatible, the error-message should >> IMHO be different (or is this assumption wrong)? >> >> Or is there no JCE-integration? If so, how could I use ECC with >> Ed25519 using BC-internal API? For RSA, there's the class RSAEngine >> (just like for AES, Twofish etc.), but I didn't find any EdECEngine >> or Ed25519Engine. >> >> Best regards, >> >> Marco :-) SEEBURGER AG Vorstand/SEEBURGER Executive Board: Sitz der Gesellschaft/Registered Office: Axel Haas, Michael Kleeberg, Axel Otto, 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. |
Hi again,
I read a bit more about this and I think it does not fit my needs. A KeyAgreement requires two parties and both parties must have an EC-key-pair. I have only 1 key-pair. The other side is anonymous. Also I'm asking all this also for an additional, different use-case. But both use-cases have in common that they are not a classic 2-person-talk-with-each-other use-case. In both cases, I really need simple key-chaining, i.e. an ephemeral secret key being encrypted by an asymmetric public key. There is no 2nd key-pair involved. A key-exchange is thus IMHO not what I need. Of course, the way I understand it, I could generate an ephemeral 2nd EC-key-pair used as a throw-away-instance. This ephemeral public key could then be transported together with the actual message. So the receipient, rather than decrypting normally (as it does with RSA and a Cipher instance) would first run a KeyAgreement with the ephemeral public-key it received and its own private key. But this seems rather awkward. Any ideas on this? Btw. besides the current use-case (for a customer) where only 1 side (the receipient of the messages) has a key-pair and the sender sends anonymously (but encrypted), I have this public (open-source, free software) use-case: http://subshare.org/ Here I manage a cryptographic tree, which is explained here: http://subshare.org/latest-stable/documentation/security.html ...under "Chaining cryptographic algorithms". Maybe this makes it a bit clearer, why I cannot easily use a KeyAgreement. I cannot talk much about the closed source project, but the way I understand it, the 2 use-cases are similar. Cheers, Marco :-) Am 29.09.20 um 14:17 schrieb Eckenfels. Bernd: > Hello Marco, > > using a key agreement for EC encryption is quite normal, you should not deviate from this. If you need to use key transport instead (encrypt your existing session key), then you can use the X25519 key agreement to get the ephemeral key and use that one to wrap your existing session key. This is for example used for S/Mime, as far as I remeber. S/Mime uses ECMQV Key agreement. > > Gruss > Bernd > > -----Ursprüngliche Nachricht----- > Von: Marco Nguitragool <[hidden email]> > Gesendet: Dienstag, 29. September 2020 04:15 > An: [hidden email] > Betreff: Re: [dev-crypto] EdEC / Ed25519 Cipher? > > Hi David, > > thanks a lot! I'm going to read about it and give X25519 a try. > > I thought / hoped that the JCA's Cipher-API can be used with ECC, too. Otherwise I'd have to refactor the entire application :-( > > Hmmm... I already started reading and X25519 is a Diffie-Hellman-function. So it does actually too much, already, if I understand it correctly. The code which currently uses RSA -- and should be switched to ECC -- encrypts a random ephemeral key (used for symmetric crypto). > > Well, I think I need to do read more about this topic... > > Best regards, Marco :-) > > > > Am 25.09.20 um 04:56 schrieb David Hook: >> Ed25519 is specifically for signing. >> >> For anything involving encryption you want to be using X25519 or X448 >> if you're trying to use Edwards Curves. Encryption using EC curves is >> different to RSA, I would recommend reading up on these differences >> before going any further, it's not overly complicated, just requires a >> slightly different mindset. >> >> Regards, >> >> David >> >> On 24/9/20 1:59 am, Marco Nguitragool wrote: >>> Hello, >>> >>> I'm wondering how to use Elliptic-Curve-Cryptography preferrably with >>> Ed25519 instead of RSA to encrypt some data (a random symmetric key, >>> actually). >>> >>> Using RSA, I could -- when using the JCA -- instantiate a Cipher with >>> a cipher-transformation like e.g. >>> "RSA/ECB/OAEPWithSHA-256AndMGF1Padding". In order to generate an >>> RSA-key, I can use the KeyPairGenerator with the algorithm "RSA". >>> >>> But I didn't find a way to do this with ECC. I analysed the >>> BouncyCastle-sources a bit and did some experiments -- and for the >>> key-generation, the following code works: >>> >>> KeyPairGenerator keyPairGenerator = >>> KeyPairGenerator.getInstance(EdDSAParameterSpec.Ed25519, >>> BouncyCastleProvider.PROVIDER_NAME); >>> AlgorithmParameterSpec keyGenParam = new >>> EdDSAParameterSpec(EdDSAParameterSpec.Ed25519); >>> keyPairGenerator.initialize(keyGenParam, random); >>> keyPairGenerator.generateKeyPair(); >>> >>> But I didn't find any way to obtain a cipher, yet. I checked >>> >>> >>> org.bouncycastle.jce.provider.BouncyCastleProvider.ASYMMETRIC_CIPHERS >>> >>> and there is "EdEC". But trying >>> >>> Cipher.getInstance("EdEC/ECB/OAEPWithSHA-256AndMGF1Padding", >>> BouncyCastleProvider.PROVIDER_NAME); >>> >>> does not work. Neither does "Ed25519" instead of "EdEC". >>> >>> I'm not sure, whether this padding makes even sense in this context, >>> but if the padding was wrong/incompatible, the error-message should >>> IMHO be different (or is this assumption wrong)? >>> >>> Or is there no JCE-integration? If so, how could I use ECC with >>> Ed25519 using BC-internal API? For RSA, there's the class RSAEngine >>> (just like for AES, Twofish etc.), but I didn't find any EdECEngine >>> or Ed25519Engine. >>> >>> Best regards, >>> >>> Marco :-) signature.asc (849 bytes) Download Attachment |
Hi Marco,
On 01/10/2020 10:53, Marco Nguitragool wrote: > Of course, the way I understand it, I could generate an ephemeral 2nd EC-key-pair used as a throw-away-instance. This ephemeral public key could then be transported together with the actual message. So the receipient, rather than decrypting normally (as it does with RSA and a Cipher instance) would first run a KeyAgreement with the ephemeral public-key it received and its own private key. But this seems rather awkward. Yes, it seems odd when you're used to the RSA way of doing things, but this is how ECIES and libsodium's sealed boxes work. Bouncy Castle has an implementation of ECIES, but I don't know whether it can be used with X25519 key pairs. If not, I think Bouncy Castle has all the parts you need for reproducing libsodium's sealed box construct. Cheers, Michael |
Hi Michal,
thanks to everyone for pointing me into this direction. I implemented this solution; i.e. I use a key-pair-generator instead of a SecureRanom -- and the generated ECC public key instead of an RSA-encrypted random byte-array. It works fine and even though it looks a bit awkward to generate such "throw-away key-pairs", it seems to be a secure and good solution. So far, I use it for my customer's project only. Don't know yet, when I'm going to have time to put this into my hobby project ;-) Cheers, Marco :-) Am 01.10.20 um 12:55 schrieb Michael Rogers: > Hi Marco, > > On 01/10/2020 10:53, Marco Nguitragool wrote: >> Of course, the way I understand it, I could generate an ephemeral 2nd EC-key-pair used as a throw-away-instance. This ephemeral public key could then be transported together with the actual message. So the receipient, rather than decrypting normally (as it does with RSA and a Cipher instance) would first run a KeyAgreement with the ephemeral public-key it received and its own private key. But this seems rather awkward. > Yes, it seems odd when you're used to the RSA way of doing things, but > this is how ECIES and libsodium's sealed boxes work. > > Bouncy Castle has an implementation of ECIES, but I don't know whether > it can be used with X25519 key pairs. If not, I think Bouncy Castle has > all the parts you need for reproducing libsodium's sealed box construct. > > Cheers, > Michael signature.asc (849 bytes) Download Attachment |
Free forum by Nabble | Edit this page |