Re: Diffie-Hellman questions

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