Re: Diffie-Hellman questions

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