[Feature]: Shorten one-time contact links with PAKE, similar to magic-wormhole or croc
ElonSatoshi opened this issue · comments
Is there an existing issue for this?
- I have searched the existing issues
Platform
all
App version
5.4.2
Feature
The very long URLS used to add contacts in SimpleX Chat are a barrier to entry, I've even seen it complained about on Reddit.
Suppose it were instead possible to add someone by typing something as short as "6-detector-talon" into the program?
And a link could look like this, maybe: https://simplex.chat/contact/#/?pake=6-detector-talon
Somehow, the relevant information that is usually conveyed through a normal SimpleX contact link would have to be encrypted via this PAKE passphrase
See also:
- https://github.com/magic-wormhole/magic-wormhole (which I'm just now noticing it maybe doesn't use PAKE, because maybe PAKE is a specific Go library)
- https://github.com/schollz/croc
- https://github.com/schollz/pake (how to port to Haskell and/or javascript?)
- https://github.com/topics/pake
Interesting.
I was thinking about it, and as everything, this seems to be a trade-off.
On one hand these links are more convenient, but on another hand they reduce the space from which to generate at least one of the key, and make proving security qualities much harder.
To put it in context, if we choose say 8 words out of a dictionary of 10000 words (which is still a rather large string), then we are getting ~132 bits worth of randomness, just a dash over 128, while we use 3 keys in the link - 1 * 256 bit and 2 * 448 bits...
I'm not a cryptography expect to reason about the security parameters here, but it does seem like a compromise that may be ok for passing wormhole or croc links which are usually passed via pre-existing moderately secure connections, and that are also short-lived, as opposed to SimpleX invitation links that are often passed via less secure channels and one of the keys is not-so-short lived...
I agree with the objective of increasing the friendliness of the links, but it feels like PAKE2 might be neither sufficiently friendly (still a long link), nor sufficiently secure (a lot less randomness), and at the same time it would require some work and complexity to implement.
The direction to offer shorter mnemonic addresses seems both more friendly and something that won't compromise security (even though it would add an identity server to the mix, though we think the server would only see this identity rather than its contacts, plus it would remain optional.
We should reconsider it later though.
I'm not a cryptography expect to reason about the security parameters here, but it does seem like a compromise that may be ok for passing wormhole or croc links which are usually passed via pre-existing moderately secure connections, and that are also short-lived, as opposed to SimpleX invitation links that are often passed via less secure channels and one of the keys is not-so-short lived...
If you mean that wormhole/croc links can be more easily passed through audio chat or even a face-to-face conversation, then yes.
In either case, both are one-time links that should be shared securely to avoid a MITM attack. After successful connection, it's always useful to verify that there was no MITM attack. Magic wormhole does this with the --verify flag, which shows a verification string, which can be verified by the users to match before starting the file transfer. SimpleX Chat has a similar thing in which users compare their security codes and verify that they are the same. Maybe Croc doesn't have that function, which is sad.
Perhaps SimpleX Chat will come up with its own mnemonic solution? If this could be combined with XFTP, it could become a viable wormhole/croc alternative.
Maybe more than three words are needed, but cool idea.
In either case, both are one-time links that should be shared securely to avoid a MITM attack.
It's not as simple as that. To mitigate MITM in both cases it's sufficient to have a channel that cannot replace the link, it does not need to be secure in a sense that it protects the content from eavesdropping/interception.
But replacing the full key with multiple words, even in case of using 8 words out of 10000 vocabulary, substantially reduces the cost of compromising shared secret by eavesdropping, without the need for MITM. Whether this cost is still within an acceptable range is arguable, but 8 words is a lot, and 10000 words vocabulary is substantially larger than a vocabulary that can be confidently used by an average person over the phone line. If we are talking about 3-4 words out of more realistic 5000 words vocabulary, then instead of 132 bits of randomness we are getting 37-49 bits of randomness.
Assuming that a modern computer can try up to a billion (10^9) values per second, then it would be take 2 minutes for 3 words and 6.5 days for 4 words to brute force the private key for a given public key, unless I am missing something here. 2 minutes feels like not too much even for very short lived links, and even the ability to recover a private key for a given public address in 6.5 days is also rather catastrophic security failure. Possibly it's not as bad, but it seems simply unnecessary given the direction.
And don't forget that with probability of 50% the attack would take less than half of whatever maximum required time.
It might be important to note that one can just send a SimpleX link over wormhole/croc right now, as long as the other person has the same software.