4 ms·

http://matrix.org/docs/guides/e2e_implementation.html http://matrix.org/docs/guides/e2e_implementation.html I need to tear into this later, but I really hope t

http://matrix.org/docs/guides/e2e_implementation.html http://matrix.org/docs/guides/e2e_implementation.html I need to tear into this later, but I really hope they're not implementing multi-party ECDH (which is perilous even if you're using X25519; if anyone thinks about going down this route, please hire a cryptographer).

deleted 10y ago
[deleted]
godelski 10y ago
For someone who knows very little about this subject, could you elaborate?
- CiPHPerCoder 10y ago
  I'm working on publishing some research in this specific slice of cryptography in the next couple of weeks, but briefly. Alice, Bob, and Charlie are chatting securely. Using the notation where lowercase indicates secret key and uppercase indicates public keys: s0 = aBC = bAC = cAB Debora joins the conversation. s1 = aBCD = bACD = cABD = dABC What does Debora see? In naive implementations, the output of the previous handshake (s0) is given to Debora to mix with her secret key. This isn't a good design (and you can't do this with the implementations of X25519 I've reviewed, e.g. libsodium's), but that's not obvious to someone who's never studied these kind of protocols before. Now they decide to oust Charlie from the group. How do you handle revocation safely and efficiently? If you combine the two issues above, you create a join-slurp-leave loop that gives you the secret keys of conversations that take place while you are absent. (This is an active attack, of course.) Let's say Bob's laptop is stolen. Does mpECDH have forward security-baked in? No. (Protocols like Signal's do.) So you add forward secrecy. Great, now how do you know the server isn't replacing public keys since they're changing frequently? These are just a sample of the kind of challenges one faces when they venture down this road. If you ask almost any cryptographer, they'll have a somewhat reasonable answer for these challenges. But a non-crypto dev would, with all likelihood, not think to even ask.
  - godelski 10y ago
    That makes a lot more sense. Thank you for the reply.
no_protocol 10y ago
They say that their "Olm" library is an implementation of the "Double Ratchet" algorithm: https://whispersystems.org/docs/specifications/doubleratchet/ https://whispersystems.org/docs/specifications/doubleratchet...
deleted 10y ago
[deleted]
Arathorn 10y ago
we're not. plus we hired cryptographers: https://www.nccgroup.trust/us/our-research/matrix-olm-cryptographic-review https://www.nccgroup.trust/us/our-research/matrix-olm-crypto... :)
- CiPHPerCoder 10y ago
  Excellent! This should go in a top-level comment so folks can review the audit and study its findings.

deleted 10y ago

[deleted]

godelski 10y ago

For someone who knows very little about this subject, could you elaborate?

CiPHPerCoder 10y ago
I'm working on publishing some research in this specific slice of cryptography in the next couple of weeks, but briefly. Alice, Bob, and Charlie are chatting securely. Using the notation where lowercase indicates secret key and uppercase indicates public keys: s0 = aBC = bAC = cAB Debora joins the conversation. s1 = aBCD = bACD = cABD = dABC What does Debora see? In naive implementations, the output of the previous handshake (s0) is given to Debora to mix with her secret key. This isn't a good design (and you can't do this with the implementations of X25519 I've reviewed, e.g. libsodium's), but that's not obvious to someone who's never studied these kind of protocols before. Now they decide to oust Charlie from the group. How do you handle revocation safely and efficiently? If you combine the two issues above, you create a join-slurp-leave loop that gives you the secret keys of conversations that take place while you are absent. (This is an active attack, of course.) Let's say Bob's laptop is stolen. Does mpECDH have forward security-baked in? No. (Protocols like Signal's do.) So you add forward secrecy. Great, now how do you know the server isn't replacing public keys since they're changing frequently? These are just a sample of the kind of challenges one faces when they venture down this road. If you ask almost any cryptographer, they'll have a somewhat reasonable answer for these challenges. But a non-crypto dev would, with all likelihood, not think to even ask.
- godelski 10y ago
  That makes a lot more sense. Thank you for the reply.

no_protocol 10y ago

They say that their "Olm" library is an implementation of the "Double Ratchet" algorithm: https://whispersystems.org/docs/specifications/doubleratchet/ https://whispersystems.org/docs/specifications/doubleratchet...

deleted 10y ago

[deleted]

Arathorn 10y ago

we're not. plus we hired cryptographers: https://www.nccgroup.trust/us/our-research/matrix-olm-cryptographic-review https://www.nccgroup.trust/us/our-research/matrix-olm-crypto... :)

CiPHPerCoder 10y ago
Excellent! This should go in a top-level comment so folks can review the audit and study its findings.