Re: Diffie-Hellman questions

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