Re: Diffie-Hellman questions

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 <[email protected]
> <mailto:[email protected]>> 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 <[email protected]
>     <mailto:[email protected]>> 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 <[email protected]
>>     <mailto:[email protected]>> 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 <[email protected]
>>         <mailto:[email protected]>> 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
>>