Ability to export/import current E2E state as a passphrased blob

[ara4n]

This would be useful for backup purposes (e.g. being able to resurrect my identity key & room key data after moving browser sessions) as well as a temporary mitigation for not being able to share room key data with my new devices in a room in order to share historical data.

[ara4n]

We should probably never store/restore the identity keypair itself, given the act of restoring this onto a new browser should presumably be seen as a new device for the purposes of verification etc.

[apexo]

Should we use some key-derivation function (e.g. PBKDF2/bcyrpt/scrypt/argon2) to make brute-forcing the passphrase harder?

The "identity keypair" is in session.e2e.account?

[ara4n]

@apexo: yup, something like bcrypt sounds sensible.

and yup, sessione.e2e.account looks like the identity key details.

[eternaleye]

@ara4n:

Please, please do not use bcrypt. The reason it was ever used is that Blowfish's key setup was - at the time - considered hard to accelerate efficiently, and the world has changed since then. Bruce Schneier, who created Blowfish, said in 2007 that he was "amazed it was still being used".

In addition, there's a significant amount of ongoing research regarding memory-hard functions (an incredibly important paper on upper-bounds and optimal security was just published this month and last revised today, and includes new attacks on Argon2i).

Scrypt operates on data in secret-dependent ways (and thus potentially has side-channel problems that are especially relevant if running it on the client device), and while Argon2 has a mode that does not (Argon2i), when submitted to the IRTF CFRG, there was significant concern over both its newness and its security bounds.

I strongly suggest going with PBKDF2, as it's well-understood, widely-deployed, supported by almost everything, and not the subject of active research.

[apexo]

The problem with PBKDF2 is that hashing is serial: it can only every utilize a single thread. If you want to limit the latency that is required to verify a hash, you can only throw so many iterations at it.

An attacker, however, is not limited by latency. He can employ a vast array of efficient (=slower) computing units that specialize on hashing. So even if one hash takes longer, it doesn't matter much, since he can compute thousands or even millions of hashes in parallel.

scrypt and Argon2 don't suffer as much, because they also require a lot of memory, which limits parallelism attacks. Argon2 improves upon that by incorporating parallelism: generating a single hash can use multiple threads, which gives attackers less of an advantage.

Yes, there are attacks on scrypt and Argon2 that can trade memory for CPU time. That's unfortunate, but I'd argue that they are still better than PBKDF2, which has no protection at all against parallelism attacks.

[eternaleye]

@apexo: Please see the "incredibly important paper" I linked: scrypt, being data-dependent, has known issues when used on secret data in circumstances where an attacker could perform side-channel attacks (as would be the case here), and Argon2's security parameter has been repeatedly eroded by a large margin in the past few months.

The former is not quite suited for the use case, and the latter is not ready.

Moreover, there's the question of well-studied, vetted implementations being available for use in the browser. PBKDF2 wins here by a large margin, being supported by the WebCrypto standard. (On older browsers, one can trivially implement PBKDF2 on top of HMAC, and be constant-time - while Javascript will badly magnify the data-dependence of scrypt).

That same paper I linked also finds a family of graphs (and by such, a family of algorithms) with optimal memory hardness. I strongly suspect that within the next 6-12 months, those will be usable, and they would entirely obsolete Argon2.

[richvdh]

I've proposed a format for this (including proposals for encryption) at https://docs.google.com/document/d/1UjWpNMfof3ynFbEOtHWGmqxy_WrFZEojrGWUq_os0G8. I'd be grateful for comments from interested parties.