You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 18, 2021. It is now read-only.
Repository navigation
This repository was archived by the owner on Feb 18, 2021. It is now read-only.
e3x: mention future/forward secrecy, add comparison with OTR, Axolotl? #117
Would it be useful to just state how e3x is similar/different from the future/forward secret approaches of OTR and the Axolotl ratchet? I know there's a list of links, but I'll admit I'm not sure how e3x fits into the universe that Marlinspike describes here: https://whispersystems.org/blog/advanced-ratcheting/
You get forward secrecy because a handshake uses ephemeral keys to generate the session key for an exchange. The notion of "future secrecy" isn't really clear to me. Moxie brings it up to illustrate problems with deriving new session keys from previous session keys, which e3x doesn't do.
Ratcheting makes sense in store-and-forward messaging, but e3x is about real time communication between two endpoints.
You can generate new ephemeral keys and send new handshakes, but they have no coupling or relationship with previous ones, they just have to be "newer" (have a higher sequence).
If you generate a new hashname though, you'll need an app-level mechanism to re-register or re-associate trust at a higher level.
A better comparison table/breakdown would be great and should eventually happen, on my radar first though is just getting some better api/docs/examples out to help make v3 more immediately usable :)
I'm working on this. I'd definitely like to see PFS and deniability among the features one is comparing. I still need to understand better this idea of "future secrecy".
Activity
dvanduzer commentedon Jan 18, 2015
You get forward secrecy because a handshake uses ephemeral keys to generate the session key for an exchange. The notion of "future secrecy" isn't really clear to me. Moxie brings it up to illustrate problems with deriving new session keys from previous session keys, which e3x doesn't do.
Ratcheting makes sense in store-and-forward messaging, but e3x is about real time communication between two endpoints.
ariddell commentedon Jan 18, 2015
Ok, I think I got it. You're sending streams between peers so there's no chance to generate a new key as one would with OTR. Is that right?
quartzjer commentedon Jan 19, 2015
You can generate new ephemeral keys and send new handshakes, but they have no coupling or relationship with previous ones, they just have to be "newer" (have a higher sequence).
If you generate a new hashname though, you'll need an app-level mechanism to re-register or re-associate trust at a higher level.
A better comparison table/breakdown would be great and should eventually happen, on my radar first though is just getting some better api/docs/examples out to help make v3 more immediately usable :)
quartzjer commentedon Jan 25, 2015
@ariddell do you have any examples of tables and/or lists of columns you'd like here? Happy to convert the list to a table soon.
ariddell commentedon Jan 27, 2015
I'm working on this. I'd definitely like to see PFS and deniability among the features one is comparing. I still need to understand better this idea of "future secrecy".
ariddell commentedon Jan 30, 2015
(just for my own reference, I'm thinking about the "Comparison" section at https://github.com/telehash/telehash.org/blob/master/v3/e3x/README.md)
Another one to include could be ntor (spec).