Diffie-Hellman questions

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

Diffie-Hellman questions

Raul Acevedo
I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.

There are a couple approaches I'm considering:

1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.

2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.

My two questions are:

1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.

2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?

Any help greatly appreciated. Thanks,

Raul
Reply | Threaded
Open this post in threaded view
|

Re: Diffie-Hellman questions

Uri Blumenthal
Yes, #1 is much better than #2, with one correction.

Use ECDHE - Elliptic Curve-based Ephemeral Diffie-Hellman. But KDF is still needed.

Deriving keys from long-term whatever is a bad alternative, KDF or not.

Sent from my test iPhone

> On Feb 25, 2019, at 14:21, Raul Acevedo <[hidden email]> wrote:
>
> I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.
>
> There are a couple approaches I'm considering:
>
> 1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.
>
> 2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.
>
> My two questions are:
>
> 1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.
>
> 2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?
>
> Any help greatly appreciated. Thanks,
>
> Raul

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Diffie-Hellman questions

Raul Acevedo
Excellent, thank you. Currently I'm prototyping using ephemeral EC key pairs generated every time, and ECCDHwithSHA384CKDF with AgreedKeyWithMacKey to derive the secret on both ends.

Can I skip the key material in this case? I.e.:

            KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
            agreement.init(initiatorPrivateKey); // Do I need this: new UserKeyingMaterialSpec((initiator + KEY_MATERIAL + recipient).getBytes()));
            agreement.doPhase(recipientPublic, true);
            AgreedKeyWithMacKey agreedKey = (AgreedKeyWithMacKey) agreement.generateSecret("CMAC[128]/AES[256]");

I'm working off of "Example 47 – ECCDH Key Agreement with Key Confirmation", BCFipsIn100.pdf, p. 42.

Thanks again,

Raul

On Mon, Feb 25, 2019 at 11:39 AM Uri Blumenthal <[hidden email]> wrote:
Yes, #1 is much better than #2, with one correction.

Use ECDHE - Elliptic Curve-based Ephemeral Diffie-Hellman. But KDF is still needed.

Deriving keys from long-term whatever is a bad alternative, KDF or not.

Sent from my test iPhone

> On Feb 25, 2019, at 14:21, Raul Acevedo <[hidden email]> wrote:
>
> I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.
>
> There are a couple approaches I'm considering:
>
> 1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.
>
> 2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.
>
> My two questions are:
>
> 1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.
>
> 2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?
>
> Any help greatly appreciated. Thanks,
>
> Raul
Reply | Threaded
Open this post in threaded view
|

Re: Diffie-Hellman questions

Uri Blumenthal
Offhand, I think your can - because in this case is already done for you.

Let those who dealt with this API more correct me.

Sent from my test iPhone

On Feb 25, 2019, at 14:53, Raul Acevedo <[hidden email]> wrote:

Excellent, thank you. Currently I'm prototyping using ephemeral EC key pairs generated every time, and ECCDHwithSHA384CKDF with AgreedKeyWithMacKey to derive the secret on both ends.

Can I skip the key material in this case? I.e.:

            KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
            agreement.init(initiatorPrivateKey); // Do I need this: new UserKeyingMaterialSpec((initiator + KEY_MATERIAL + recipient).getBytes()));
            agreement.doPhase(recipientPublic, true);
            AgreedKeyWithMacKey agreedKey = (AgreedKeyWithMacKey) agreement.generateSecret("CMAC[128]/AES[256]");

I'm working off of "Example 47 – ECCDH Key Agreement with Key Confirmation", BCFipsIn100.pdf, p. 42.

Thanks again,

Raul

On Mon, Feb 25, 2019 at 11:39 AM Uri Blumenthal <[hidden email]> wrote:
Yes, #1 is much better than #2, with one correction.

Use ECDHE - Elliptic Curve-based Ephemeral Diffie-Hellman. But KDF is still needed.

Deriving keys from long-term whatever is a bad alternative, KDF or not.

Sent from my test iPhone

> On Feb 25, 2019, at 14:21, Raul Acevedo <[hidden email]> wrote:
>
> I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.
>
> There are a couple approaches I'm considering:
>
> 1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.
>
> 2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.
>
> My two questions are:
>
> 1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.
>
> 2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?
>
> Any help greatly appreciated. Thanks,
>
> Raul

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Diffie-Hellman questions

Raul Acevedo
My concern with the key material is that nowhere does the BC documentation specify what this mysterious key material should be.

Is it a randomly generated nonce? A static string? What is the proper length? Is it considered public (the parties share it when they exchange public keys) or private (how do the parties share it if it's random)?

On Mon, Feb 25, 2019 at 12:05 PM Uri Blumenthal <[hidden email]> wrote:
Offhand, I think your can - because in this case is already done for you.

Let those who dealt with this API more correct me.

Sent from my test iPhone

On Feb 25, 2019, at 14:53, Raul Acevedo <[hidden email]> wrote:

Excellent, thank you. Currently I'm prototyping using ephemeral EC key pairs generated every time, and ECCDHwithSHA384CKDF with AgreedKeyWithMacKey to derive the secret on both ends.

Can I skip the key material in this case? I.e.:

            KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
            agreement.init(initiatorPrivateKey); // Do I need this: new UserKeyingMaterialSpec((initiator + KEY_MATERIAL + recipient).getBytes()));
            agreement.doPhase(recipientPublic, true);
            AgreedKeyWithMacKey agreedKey = (AgreedKeyWithMacKey) agreement.generateSecret("CMAC[128]/AES[256]");

I'm working off of "Example 47 – ECCDH Key Agreement with Key Confirmation", BCFipsIn100.pdf, p. 42.

Thanks again,

Raul

On Mon, Feb 25, 2019 at 11:39 AM Uri Blumenthal <[hidden email]> wrote:
Yes, #1 is much better than #2, with one correction.

Use ECDHE - Elliptic Curve-based Ephemeral Diffie-Hellman. But KDF is still needed.

Deriving keys from long-term whatever is a bad alternative, KDF or not.

Sent from my test iPhone

> On Feb 25, 2019, at 14:21, Raul Acevedo <[hidden email]> wrote:
>
> I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.
>
> There are a couple approaches I'm considering:
>
> 1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.
>
> 2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.
>
> My two questions are:
>
> 1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.
>
> 2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?
>
> Any help greatly appreciated. Thanks,
>
> Raul
Reply | Threaded
Open this post in threaded view
|

Re: Diffie-Hellman questions

Uri Blumenthal
Key material is what you get from Diffie-Hellman.   To ensure the actual shatter key is uniformly distributed, this material is fed to KDF that randomizes it properly.

Sent from my test iPhone

On Feb 25, 2019, at 15:10, Raul Acevedo <[hidden email]> wrote:

My concern with the key material is that nowhere does the BC documentation specify what this mysterious key material should be.

Is it a randomly generated nonce? A static string? What is the proper length? Is it considered public (the parties share it when they exchange public keys) or private (how do the parties share it if it's random)?

On Mon, Feb 25, 2019 at 12:05 PM Uri Blumenthal <[hidden email]> wrote:
Offhand, I think your can - because in this case is already done for you.

Let those who dealt with this API more correct me.

Sent from my test iPhone

On Feb 25, 2019, at 14:53, Raul Acevedo <[hidden email]> wrote:

Excellent, thank you. Currently I'm prototyping using ephemeral EC key pairs generated every time, and ECCDHwithSHA384CKDF with AgreedKeyWithMacKey to derive the secret on both ends.

Can I skip the key material in this case? I.e.:

            KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
            agreement.init(initiatorPrivateKey); // Do I need this: new UserKeyingMaterialSpec((initiator + KEY_MATERIAL + recipient).getBytes()));
            agreement.doPhase(recipientPublic, true);
            AgreedKeyWithMacKey agreedKey = (AgreedKeyWithMacKey) agreement.generateSecret("CMAC[128]/AES[256]");

I'm working off of "Example 47 – ECCDH Key Agreement with Key Confirmation", BCFipsIn100.pdf, p. 42.

Thanks again,

Raul

On Mon, Feb 25, 2019 at 11:39 AM Uri Blumenthal <[hidden email]> wrote:
Yes, #1 is much better than #2, with one correction.

Use ECDHE - Elliptic Curve-based Ephemeral Diffie-Hellman. But KDF is still needed.

Deriving keys from long-term whatever is a bad alternative, KDF or not.

Sent from my test iPhone

> On Feb 25, 2019, at 14:21, Raul Acevedo <[hidden email]> wrote:
>
> I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.
>
> There are a couple approaches I'm considering:
>
> 1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.
>
> 2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.
>
> My two questions are:
>
> 1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.
>
> 2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?
>
> Any help greatly appreciated. Thanks,
>
> Raul

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Diffie-Hellman questions

Raul Acevedo
You would think "key material" is the result of DH, but that's not what they are talking about. Here's the full code sample from BCFipsIn100.pdf (https://www.bouncycastle.org/fips-java/BCFipsIn100.pdf), p. 41:

    public static byte[] initiatorAgreementWithKdf(PrivateKey initiatorPrivate, PublicKey recipientPublic, byte[] userKeyingMaterial) throws GeneralSecurityException {
        KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
        agreement.init(initiatorPrivate, new UserKeyingMaterialSpec(userKeyingMaterial));
        agreement.doPhase(recipientPublic, true);
        SecretKey agreedKey = agreement.generateSecret("AES[256]");
        return agreedKey.getEncoded();
    }

The byte[] result of this function is the shared DH secret. But note that "userKeyingMaterial" argument; on p. 38 there is an earlier example using "Basic DH Agreement" without userKeyingMaterial/KDF, but then they say this:

"The symmetric key is derived directly from the public private key calculation between the two parties so the derivation will always produce the same value if the same key pairs are involved. Another issue with this approach is the key size is restricted to the size of the shared secret calculated in the protocol. A fact which can also limit the usefulness of the result.

The answer in this case is to make use of what is called user keying material and a KDF. SP 800-56B specifies a KDF construction called the Concatenation KDF, or in our case “CKDF” for short. The user keying material and the use of the KDF both help mask the secret, randomise the result and allow for as much data as is required to be generated (for sensible values of required)."

I'm asking about this "user keying material". Is it a random set of bytes, generated by Alice and sent to Bob in the same way Alice sends her public keys, i.e. in public? There is no mention on the details of this "user keying material" anywhere.

On Mon, Feb 25, 2019 at 1:05 PM Uri Blumenthal <[hidden email]> wrote:
Key material is what you get from Diffie-Hellman.   To ensure the actual shatter key is uniformly distributed, this material is fed to KDF that randomizes it properly.

Sent from my test iPhone

On Feb 25, 2019, at 15:10, Raul Acevedo <[hidden email]> wrote:

My concern with the key material is that nowhere does the BC documentation specify what this mysterious key material should be.

Is it a randomly generated nonce? A static string? What is the proper length? Is it considered public (the parties share it when they exchange public keys) or private (how do the parties share it if it's random)?

On Mon, Feb 25, 2019 at 12:05 PM Uri Blumenthal <[hidden email]> wrote:
Offhand, I think your can - because in this case is already done for you.

Let those who dealt with this API more correct me.

Sent from my test iPhone

On Feb 25, 2019, at 14:53, Raul Acevedo <[hidden email]> wrote:

Excellent, thank you. Currently I'm prototyping using ephemeral EC key pairs generated every time, and ECCDHwithSHA384CKDF with AgreedKeyWithMacKey to derive the secret on both ends.

Can I skip the key material in this case? I.e.:

            KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
            agreement.init(initiatorPrivateKey); // Do I need this: new UserKeyingMaterialSpec((initiator + KEY_MATERIAL + recipient).getBytes()));
            agreement.doPhase(recipientPublic, true);
            AgreedKeyWithMacKey agreedKey = (AgreedKeyWithMacKey) agreement.generateSecret("CMAC[128]/AES[256]");

I'm working off of "Example 47 – ECCDH Key Agreement with Key Confirmation", BCFipsIn100.pdf, p. 42.

Thanks again,

Raul

On Mon, Feb 25, 2019 at 11:39 AM Uri Blumenthal <[hidden email]> wrote:
Yes, #1 is much better than #2, with one correction.

Use ECDHE - Elliptic Curve-based Ephemeral Diffie-Hellman. But KDF is still needed.

Deriving keys from long-term whatever is a bad alternative, KDF or not.

Sent from my test iPhone

> On Feb 25, 2019, at 14:21, Raul Acevedo <[hidden email]> wrote:
>
> I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.
>
> There are a couple approaches I'm considering:
>
> 1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.
>
> 2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.
>
> My two questions are:
>
> 1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.
>
> 2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?
>
> Any help greatly appreciated. Thanks,
>
> Raul
Reply | Threaded
Open this post in threaded view
|

Re: Diffie-Hellman questions

David Hook-3
In reply to this post by Raul Acevedo

If you're referring to user keying material, which it looks like you are, it's just a random string. You can consider it public and only one side needs to generate it (alternately, both sides can and you can concatenate the result), it's worth using as together with the KDF it helps blind the key exchange to the agreed value that was calculated.

Regards,

David

On 26/2/19 7:09 am, Raul Acevedo wrote:
My concern with the key material is that nowhere does the BC documentation specify what this mysterious key material should be.

Is it a randomly generated nonce? A static string? What is the proper length? Is it considered public (the parties share it when they exchange public keys) or private (how do the parties share it if it's random)?

On Mon, Feb 25, 2019 at 12:05 PM Uri Blumenthal <[hidden email]> wrote:
Offhand, I think your can - because in this case is already done for you.

Let those who dealt with this API more correct me.

Sent from my test iPhone

On Feb 25, 2019, at 14:53, Raul Acevedo <[hidden email]> wrote:

Excellent, thank you. Currently I'm prototyping using ephemeral EC key pairs generated every time, and ECCDHwithSHA384CKDF with AgreedKeyWithMacKey to derive the secret on both ends.

Can I skip the key material in this case? I.e.:

            KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
            agreement.init(initiatorPrivateKey); // Do I need this: new UserKeyingMaterialSpec((initiator + KEY_MATERIAL + recipient).getBytes()));
            agreement.doPhase(recipientPublic, true);
            AgreedKeyWithMacKey agreedKey = (AgreedKeyWithMacKey) agreement.generateSecret("CMAC[128]/AES[256]");

I'm working off of "Example 47 – ECCDH Key Agreement with Key Confirmation", BCFipsIn100.pdf, p. 42.

Thanks again,

Raul

On Mon, Feb 25, 2019 at 11:39 AM Uri Blumenthal <[hidden email]> wrote:
Yes, #1 is much better than #2, with one correction.

Use ECDHE - Elliptic Curve-based Ephemeral Diffie-Hellman. But KDF is still needed.

Deriving keys from long-term whatever is a bad alternative, KDF or not.

Sent from my test iPhone

> On Feb 25, 2019, at 14:21, Raul Acevedo <[hidden email]> wrote:
>
> I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.
>
> There are a couple approaches I'm considering:
>
> 1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.
>
> 2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.
>
> My two questions are:
>
> 1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.
>
> 2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?
>
> Any help greatly appreciated. Thanks,
>
> Raul


Reply | Threaded
Open this post in threaded view
|

Re: Diffie-Hellman questions

Raul Acevedo
Thank you David! Does the string length matter? One idea was for Alice to generate one set of random bytes, Bob to generate another, and the actual key material used by both sides is the XOR of the bytes. Is that overkill?

Also, per my original email... If we don't already have long term encryption keys, and only long term X509 certs, should we derive ephemeral keys from X509 or just create new ephemeral keys every time? Could we just use ECCDH Basic Agreement without KDF/key material in that case, or would you still recommend KDF/key material for new, per use, non-derived ephemeral keys?

Thank you very much for the help,

Raul

On Mon, Feb 25, 2019 at 10:20 PM David Hook <[hidden email]> wrote:

If you're referring to user keying material, which it looks like you are, it's just a random string. You can consider it public and only one side needs to generate it (alternately, both sides can and you can concatenate the result), it's worth using as together with the KDF it helps blind the key exchange to the agreed value that was calculated.

Regards,

David

On 26/2/19 7:09 am, Raul Acevedo wrote:
My concern with the key material is that nowhere does the BC documentation specify what this mysterious key material should be.

Is it a randomly generated nonce? A static string? What is the proper length? Is it considered public (the parties share it when they exchange public keys) or private (how do the parties share it if it's random)?

On Mon, Feb 25, 2019 at 12:05 PM Uri Blumenthal <[hidden email]> wrote:
Offhand, I think your can - because in this case is already done for you.

Let those who dealt with this API more correct me.

Sent from my test iPhone

On Feb 25, 2019, at 14:53, Raul Acevedo <[hidden email]> wrote:

Excellent, thank you. Currently I'm prototyping using ephemeral EC key pairs generated every time, and ECCDHwithSHA384CKDF with AgreedKeyWithMacKey to derive the secret on both ends.

Can I skip the key material in this case? I.e.:

            KeyAgreement agreement = KeyAgreement.getInstance("ECCDHwithSHA384CKDF", "BCFIPS");
            agreement.init(initiatorPrivateKey); // Do I need this: new UserKeyingMaterialSpec((initiator + KEY_MATERIAL + recipient).getBytes()));
            agreement.doPhase(recipientPublic, true);
            AgreedKeyWithMacKey agreedKey = (AgreedKeyWithMacKey) agreement.generateSecret("CMAC[128]/AES[256]");

I'm working off of "Example 47 – ECCDH Key Agreement with Key Confirmation", BCFipsIn100.pdf, p. 42.

Thanks again,

Raul

On Mon, Feb 25, 2019 at 11:39 AM Uri Blumenthal <[hidden email]> wrote:
Yes, #1 is much better than #2, with one correction.

Use ECDHE - Elliptic Curve-based Ephemeral Diffie-Hellman. But KDF is still needed.

Deriving keys from long-term whatever is a bad alternative, KDF or not.

Sent from my test iPhone

> On Feb 25, 2019, at 14:21, Raul Acevedo <[hidden email]> wrote:
>
> I want to use DH to encrypt data between two parties using BCFIPS and with forward secrecy. The parties have X509 publicly signed certificates to identify themselves to each other, similar to TLS.
>
> There are a couple approaches I'm considering:
>
> 1. Generate new ephemeral EC keys every time, and use ECCDH Basic Agreement. The public keys are exchanged by signing with their respective long term signing keys. No key material/KDF needed.
>
> 2. Generate ephemeral keys derived from their long term certificate keys, throw in key material + KDF, and then generate secret. Again sign the public key exchange with x509.
>
> My two questions are:
>
> 1. Is one approach inherently better than the other? #1 is simpler; #2 may be more secure because the ephemeral keys are derived from the x509 certs.
>
> 2. How is the key material shared? It's required by both parties, so is it shared publicly along with the public keys? What criteria is there for how to generate this key material in the first place? Random bytes? Of what length? Static string enough?
>
> Any help greatly appreciated. Thanks,
>
> Raul