search

nextleap-project / countermitm

thoughts on countering mitm-attacks on autocrypt
15 stars 5 forks source link

Use a single NONCE to derive AUTH and INVITENUMBER from #64

Closed azul closed 6 years ago

azul commented 6 years ago

Bryan Ford pointed this out at the end of https://moderncrypto.org/mail-archive/messaging/2018/002539.html

Also, a trivial space/bandwidth optimization: if two or more ephemeral secrets are needed (like INVITENUMBER and AUTH), it seems like slightly more space/bandwidth-efficient and just generally preferable protocol design to have just one SEED or NONCE and use key derivation techniques to produce separate ephemeral secrets for different purposes within the workflow.

(This issue is part of the feedback on the messaging@moderncrypto mailing list #61)

azul commented 6 years ago

Main open question to me is what a good key derivation function for this purpose would be. Since the INVITENUMBER is visible to a network attacker we need to make sure there is no way to brute force the NONCE based on the use of the derived key.

Argon2 seems to be the default choice these days. It should be available in most of the frequently used languages. We'd also need to pick a parameter for the difficulty. This should probably be done in a way that is still fast enough on mobile phones for a single use and slow enough on attacker resources for the timespan defined by the expiration time of the QR code (see #63).

azul commented 6 years ago

So far we require at least 8 bytes for INVITENUMBER and AUTH. One of them will give us 64 bits of entropy. Therefor a brute force attempt will on average have to perform approx. 2^63 or 10^19 key derivations. If we choose parameters that take approx 1 sec. on an old phone... An attacker would need to be 10^14 times faster to solve this within a day (~ 10^5 sec). That could boil down to...

If we include the email address and the freshness timestamp ( see #63 ) in the seed there's also no need to worry about rainbow tables etc.

azul commented 6 years ago

One of difficulties we face within the OpenPGP ecosystem is that as far as i know all the kdfs are based on hash functions that are not memory-hard or hardened against GPU or ASIC optimization. At the same time we need the algorithm to work within a reasonable time on somewhat outdated mobile phones. Argon2 seems like the obvious answer to that problem - but that would add another dependency. In addition we'd need to pick parameters that work for everyone now and provide an upgrade path that prevents downgrade attacks.

azul commented 6 years ago

It does not look like we'll be able to rely on Argon2 in an OpenPGP context any time soon: https://lists.gnupg.org/pipermail/gnupg-devel/2018-June/033795.html

The document is currently only implemented in an OpenPGP context. So I'll close this issue for now.