Consider the use of HKDF from the output of ECDH

[jbdatko]

In the v3 spec, the shared secret of ECDH is being SHA256 and then folded to derive an AES key.

This seems like a potential issue. My impression is that hash functions, by themselves, aren't suitable as Key Derivation Functions (KDFs). The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) paper seems to suggest so as well. HKDF is also a RFC.

Essentially, the output of ECDH would be used as the MAC (called Initial Keying Material in HKDF).

The TL;DR from the paper is this:

In many applications, the input keying material is not necessarily
distributed uniformly, and the attacker may have some partial
knowledge about it (for example, a Diffie-Hellman value computed by a
key exchange protocol) or even partial control of it (as in some
entropy-gathering applications). Thus, the goal of the "extract"
stage is to "concentrate" the possibly dispersed entropy of the input
keying material into a short, but cryptographically strong,
pseudorandom key. In some applications, the input may already be a
good pseudorandom key; in these cases, the "extract" stage is not
necessary, and the "expand" part can be used alone.

The second stage "expands" the pseudorandom key to the desired
length; the number and lengths of the output keys depend on the
specific cryptographic algorithms for which the keys are needed.

I recommend at least a discussion concerning the existing v3 KDF vs the use of a more standard KDF like HKDF.

[dvanduzer]

I've been reading over section 5 and appendix B, and most of the concern is with DH applications where the DDH assumption doesn't hold. I believe DDH is considered valid for all ECDH uses in telehash.

Item 1 in section 5 caught my eye, so I found the reference: http://www.iacr.org/cryptodb/archive/2004/EUROCRYPT/2316/2316.pdf

That paper indicates that a hash function is necessary and sufficient in ECDH, so I don't see cause for concern about SHA256. So questions for others:

1. Can we limit the scope of concern to the insufficient entropy issue in section 5 item 1?
2. Does that issue apply to CS1a or CS2a or both or neither?

[jbdatko]

Thanks @dvanduzer .

For a given Pair of telehash endpoints, A and B who have have fixed EC keys in their hashname, won't ECDH P256 always product the same shared secret?

If that's the case, then whenever A talks to B they will always be using the same AES key, which will remain the same until A or B changes its EC key.

This still seems undesirable to me. I don't think you want to use the same symmetric key over such a lifetime. A KDF, that includes some changing value (salt or something) will allow for different AES keys to be established.

[temas]

For an instance of a session there is an ephemeral key pair that is generated and used. This is used with the static identity key, so the entirety of the session is unique material.

[dvanduzer]

@jbdatko Some documentation will distinguish between ECDH and ECDHE, in regard to your latest comment. CS1a uses "ECDH with the received ephemeral key" (aka ECDHE, aka not the identity ECC key) for the symmetric session key. In v3.0.0, line 27 and line 33 of the spec are contradictory, but I'm pretty sure that's a typo on line 27.

I believe DDH does not hold for RSA-based Diffie-Hellman, so HKDF would make sense if we were doing DHE_RSA. CS2a also uses ECDHE for the session key, though, so it still shouldn't be an issue.

[jbdatko]

Ah, ok. So in the ECDHE case I think we're OK. Yeah, I'll have to read the docs on the RSA case a bit more.

Thanks!

[quartzjer]

Lines 27 and 33 are contradictory on purpose, they are intentionally generating different keys, one for the specific message body, and one for the channels :)

My understanding of all of this is that the goal is to maximize available shared entropy distribution into the given required keyspace. The ECDH output for 1a is the single source of a high-entropy shared secret and is 20 bytes, with a key size of 16, the SHA redistributes it into 32 bytes and the XOR halves that uniformly to get the 16 bytes.

In the 2a case w/ RSA since PK encryption is used the shared secret key can be generated/sent directly, no transformations needed :)