5

In many implementations, the result of the Diffie-Hellman algorithm is hashed. I read that:

Hashing the shared secret point prevents an attacker from gaining more information about the EC private keys used to generate the shared point.

Could someone give me an example of how to get information about the private key with a shared secret that isn't hashed?

Guut Boy
  • 2,877
  • 16
  • 25
Raoul722
  • 2,836
  • 2
  • 20
  • 39
  • 2
    related: http://crypto.stackexchange.com/questions/11867/creating-a-secure-key – cygnusv Aug 20 '15 at 10:07
  • Thanks for the link, the topic's answer is interseting:

    "In the original Diffie-Hellman key-exchange protocol, Alice and Bob use $g^{ab}$ as their session key. This basic DH protocol is based on CDH assumption, but CDH assumption alone can not ensure that we can use all the bits securely, it can only make sure we can obtain a hard core bit which is unpredictable."

    It is a nice explanation but I would like to have more precisions about these assumptions, why even considering CDH all bits aren't secure? Why do we obtain only one hard core bit? (parity bit of the secret?) Thank in advance.

     – Raoul722 Aug 20 '15 at 13:08
  • 2
    The result of the key agreement should be put into a KBKDF, rather than being "hashed" (although the difference may be minimal). I'm not sure if ECDH is as vulnerable as ECDSA with regards to leaking the private key if the random number generator fails but maybe this idea could be the base of an answer (I'm talking about the hack by the Chaos Computer Club of the Sony private key here, in case somebody remembers that). – Maarten Bodewes Aug 20 '15 at 14:21
  • Yeah this failure is well describe on wikipedia: https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm but I don't see how could we apply this kind of attack on ECDH. – Raoul722 Aug 20 '15 at 14:32
  • Could you please indicate where that quote originated? Because other than said attack I cannot directly come up with an attack at the moment. – Maarten Bodewes Aug 20 '15 at 17:27

1 Answers1

6

I have never heard of this reason, and I don't quite understand it. In general, the security of Diffie-Hellman key exchange is reduced to the DDH assumption. According to this assumption, the result of the key exchange is a group element that is computationally indistinguishable from a random/uniformly distributed element in the group. However, what is important to note is that a uniformly distributed group element is not a uniformly distributed string (where the latter must have each bit equal 0 with probability 1/2 and equal 1 with probability 1/2). In particular, if you work in $\mathbb{Z}_p^*$ then the most significant bit will certainly not be uniformly distributed. Likewise, if you are working in an Elliptic curve group, then the result is a pair of field elements which fulfill the Elliptic curve equation. Therefore, in order to derive a uniformly distributed string, you need to apply a function that extracts a uniform string from a high entropy source. These are called extractors or key derivation functions. This is the reason that you hash.

I note that it's possible to prove the security of Diffie-Hellman key exchange under the CDH assumption and in the random oracle model. In this case, the hash function is needed to get a long pseudorandom string from a computational assumption. However, I think that explaining this here will be "too much information".

Yehuda Lindell
  • 27,820
  • 1
  • 66
  • 83
  • This answer seems very much related to my question here. Using the bits of $x$ directly probably has similar characteristics. – Maarten Bodewes Aug 20 '15 at 17:25
  • Why a uniformly distributed group element is not a uniformly distributed string? What the adversary can do apart from brute forcing?Assuming we are working in a subgroup q of big prime order p-1/2 – curious Oct 24 '16 at 18:01
  • I don't know what an adversary can do and it depends very much on what the string is used for. But, if it is used for a one-time pad, then any bias on any bits can be disastrous. If it is used in a block cipher, then having some bits biased may weaken the block cipher... – Yehuda Lindell Oct 24 '16 at 18:05