[cryptography] Security Discussion: Password Based Key Derivation for Elliptic curve Diffie–Hellman key agreement
jpixton at gmail.com
Tue Dec 17 13:38:52 EST 2013
In very general terms, you cannot hope to achieve confidentiality
Your key exchange does not offer authenticity. I would suggest instead
having the user's keys be signing keys, and do straightforward signed
ephemeral ECDH. This should also gain you forward secrecy.
Unfortunately this will introduce a data dependency in your protocol,
which may cause an unacceptable extra round trip.
With that assumed fixed, your protocol relies entirely on a third
party (the 'public key server') for authenticity of the key exchange.
If the overall aim is to avoid having to trust a third party
(Facebook) to keep messages secret, adding more third parties to the
problem doesn't seem a great solution. From your own point of view,
you should consider this a major legal and technical liability. From
your users point of view, why should they place their trust in you?
So, establishing the true authenticity keys of the recipient and
sender is absolutely vital. Consider a different way of bootstapping
everything, perhaps by having users distribute and confirm their
public keys in person, or by multiple entirely separate channels.
The symmetric step also offers no ciphertext authenticity, so you will
have a CBC padding oracle or timing attack here, allowing an
intermediary to recover messages.
Is there a reason you did not consider using OTR? Or another of the
many secure chat protocols?
On 17 December 2013 18:01, SafeChat.IM <info at safechat.im> wrote:
> Dear mailing list,
> A friend and me are working on a plugin that enables encryption on top of
> Facebook messaging. The idea is to encrypt messages before they leave the
> chat client, sending only the cipher to Facebook and decrypt the message on
> the receiver client, before it is displayed. The plugin automatically
> realizes which users have it installed and only encrypts these chats.
> Since the reliability of the cryptographic system is a crucial part of the
> design, I would to discuss the protocol here:
> First, we use PBKDF2 to derive a 256 bit data block from a passphrase the
> user chooses and a salt (the username). We advise the user to use a long and
> This data block serves as the private key for a secp256r1 elliptic curve. We
> cannot use a random private key, as we have to be able to generate the same
> private key on different devices of the user. Given this private key, and
> another user’s public key (exchange through a public key server), we
> calculate the shared key as defined in the Elliptic curve Diffie–Hellman
> (ECDH) key agreement protocol:
> Given Alice’s private key ‘a’ and the elliptic curve ‘G’ (defined by the
> secp256r1 parameters), Alice’s public key ‘A’ is defined as:
> A = a*G
> (Analogously for Bob: B = b*G)
> If Alice has her private key ‘a’ and Bob’s public key B, she can calculate
> the shared key S
> S = a*B = a*b*G
> Bob has his private key ‘b’ and Alice’s public key ‘A’ to derive the same
> S’ = b*A = b*a*G = a*b*G = S
> Tom Wu’s library  is used to implement all ECDH related stuff.
> The shared secret together with a random salt is used as a starting block to
> generate a 256bit AES key, which eventually encrypts the message. The cipher
> and the random salt are sent to the other person, so that he can reproduce
> the symmetric key. We use the Gibberish library for that purpose .
> Our process is also depicted here: http://goo.gl/ghzWSl
> Do you see a problem with that approach? I am looking forward to comments
> and concerns.
>  http://anandam.com/pbkdf2/
>  http://www-cs-students.stanford.edu/~tjw/jsbn/
>  https://github.com/mdp/gibberish-aes
> cryptography mailing list
> cryptography at randombit.net
More information about the cryptography