[148516] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography]

daemon@ATHENA.MIT.EDU (Alec Edgington)
Thu Dec 19 02:52:25 2013

X-Original-To: cryptography@metzdowd.com
Date: Thu, 19 Dec 2013 06:19:29 +0000
From: Alec Edgington <alec@obtext.com>
To: cryptography@metzdowd.com
In-Reply-To: <5B99F4E5-A069-4375-A61B-DC6BDC79CBE4@safechat.im>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

On 17/12/13 21:58, 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 hard-to-guess passphrase. We use Parvez Anandam=92s JavaScript
> implementation [1].
> =

> 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=92s public key (exchange through a
> public key server), we calculate the shared key as defined in the
> Elliptic curve Diffie=96Hellman (ECDH) key agreement protocol:

[snip]

Note that this protocol does not provide forward secrecy: if a user's
private key is ever compromised, then all past (as well as future)
messages to and from that user may be revealed. This is the danger of
using static keys for DH.

You might want to look at the station-to-station protocol, which is
designed for this sort of application. It uses ephemeral DH keys signed
by static signing keys to achieve forward secrecy.

You probably also need some way of confirming that each user got the
right public key from the server.

Cheers,
Alec
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography

home help back first fref pref prev next nref lref last post