Question about the X25519 algo versus the

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

Question about the X25519 algo versus the

Benoit Laforest

Hi,

 

We are considering using the X25519 curve for the DH key exchange in our project, between our server and our clients and we have a few interrogation.

 

  • What is the difference between directly using the X25519KeyPairGenerator and using  a DH key generator via GeneratorUtilities.GetKeyPairGenerator(“ECDH”)?

 

  • Is using the X22519 key pair generator meaning that we are using the same “hardcoded” curve on both server and clients?

 

  • If we use the other option, with the GeneratorUtilities, then we would generate our P and G parameters, we would hardcode them and use them with the DHKeyPairGenerator but would this mean that we are using a another type of curve?

 

Thanks for the help, I am pretty new to cryptography and I am still “decrypting” the concepts 😊

 

Benoit

Reply | Threaded
Open this post in threaded view
|

Re: Question about the X25519 algo versus the

David Hook-3

Answers in line.

Regards,

David

On 3/10/19 12:22 am, Benoit Laforest wrote:

Hi,

 

We are considering using the X25519 curve for the DH key exchange in our project, between our server and our clients and we have a few interrogation.

 

  • What is the difference between directly using the X25519KeyPairGenerator and using  a DH key generator via GeneratorUtilities.GetKeyPairGenerator(“ECDH”)?

Assuming it's returning a KeyPairGenerator use "XDH" rather than "ECDH". The Edwards Curves keys in Java implement different interfaces from the regular EC ones. Other than that I have no idea what GeneratorUtilities is.


 

  • Is using the X22519 key pair generator meaning that we are using the same “hardcoded” curve on both server and clients?
Yes. It is kind of the idea though, so I wouldn't worry over that one.

 

  • If we use the other option, with the GeneratorUtilities, then we would generate our P and G parameters, we would hardcode them and use them with the DHKeyPairGenerator but would this mean that we are using a another type of curve?
P and G makes it sound like you would be generating a regular Diffie-Hellman key. That's a completely different algorithm.

 

Thanks for the help, I am pretty new to cryptography and I am still “decrypting” the concepts 😊

 

Benoit


Reply | Threaded
Open this post in threaded view
|

Re: Question about the X25519 algo versus the

Peter Dettman-3
In reply to this post by Benoit Laforest
Hi Benoit,
Firstly, please note that there is a separate mailing list for the C#
API (https://bouncycastle.org/csharp/mailing_lists.html).

To your questions:

On 2/10/19 9:22 pm, Benoit Laforest wrote:
> We are considering using the X25519 curve for the DH key exchange in our
> project, between our server and our clients and we have a few interrogation.
>
>   * What is the difference between directly using the
>     */X25519KeyPairGenerator/*and using  a DH key generator via
>     *GeneratorUtilities**.**GetKeyPairGenerator**(**“ECDH”**)*?

GeneratorUtilities is intended for code that is trying to be generic
over many different algorithms. If you just want to use X25519 key
exchange, then I would recommend using X25519KeyPairGenerator directly.


>   * Is using the *X22519* *key* pair generator meaning that we are using
>     the same “hardcoded” curve on both server and clients?

X25519 uses a hard-coded curve, yes (by design). If you have to choose
just one key exchange algorithm, it's a great choice.


>   * If we use the other option, with the *GeneratorUtilities*, then we
>     would generate our *P and G parameters*, we would hardcode them and
>     use them with the *DHKeyPairGenerator*but would this mean that we
>     are using a another type of curve?

Yes, DH in this context means specifically Finite-Field Diffie-Hellman.
X25519 is an elliptic curve based Diffie-Hellman, with the elliptic
curve part treated for the most part as an implementation detail.

Although you can generate your own (FF) DH parameters, you may be better
off using standardised parameters, e.g. see:
    Org.BouncyCastle.Crypto.Agreement.DHStandardGroups

You'd probably be better off not using (FF) DH though. X25519 is a much
better choice for new systems; or if it's not feasible, then ECDH
(Elliptic Curve Diffie-Hellman).

Regards,
Pete Dettman