On 13/03/14 06:37, Tom Ritter wrote: > I think something very important for protocols we design going forward > is persistence of key material, ala ZRTP's. The encrypted > conversation I am having with Alice now is authenticated via the last > encrypted conversation I had with Alice. You can trick me by MITMing > all my conversations with Alice, but as long as I get one conversation > in that you don't - we'll be able to figure it out. >
It's not clear to me whether it would be appropriate/useful to store this stuff in the contact-verifier component I outlined below. Ratchet secrets are associated with *ongoing sessions*, which might be very long-term, but they are application-specific. (Can you think of a maybe-future-common use-case where multiple applications share the same session?) Although, perhaps it could be useful for an application that does not need any other persistent-secrets-storage, to "piggy-back" onto the service provided by the contact-verifier. I think it probably is *inappropriate* to share this state across devices (one major feature of the contact-verifier). Proper operation of ratchets involves deletion of old secrets, but this can't be done if "there might be another device that needs this". This is why I don't share my OTR keys across devices. (Some people tell me they've done it, but they also never have concurrent sessions between multiple devices.) When we have multiparty ratchets, which I am looking into, that will solve this problem as well, so I think we don't need to spend extra effort solving it separately. > My happiness with this design evolved in a good deal from discussions > with some of the folks on this list at various events. It's the > implementation I'm a wee bit nervous about, as this system needs to be > handle things like 'restarting after a lost device' and the ratcheting > issues of what happens when we aren't in the same state because I > think you received messages from me but you didn't. > This can be done with a proper understanding of what all the components of the ratchet are used for. We can derive specific conditions under which it's *safe* to delete secrets - roughly speaking, for "remote secrets", you can delete old secrets when the other person has acknowledged a new secret; and for "local-only" secrets, you can delete old secrets when you yourself have committed the new ones to persistent storage. Some rough notes here: https://github.com/infinity0/smc-notes/blob/master/ideal-ratchet.rst which is a generalised model of a ratchet, without reference to concrete crypto primitives. (Ps() and Pr() are the same as prevS() and prevR() that I mentioned in my other thread.) > -tom > > On 12 March 2014 08:18, Ximin Luo <[email protected]> wrote: >> This is a brief outline on the architecture of an independent/central >> "verification" program. This could be part of a keyring, or a contact >> manager, or even a combined contacts/keys manager that some UX folks were >> suggesting at the CTS IV. It would let a user: >> >> 1. store cryptographic material to authenticate their contact, either a >> public-key fpr, or a shared secret for kex, or whatever. >> 2. store/set the *verification status* of the material. this could be: >> - full (physical), i.e. via a physical communication of fingerprint or >> shared-secret >> - delegate, i.e. sent via a friend (the friend must themselves be >> verified). (one idea for mpOTR/groupchat is to have the initiator send all >> public keys to everyone else.) >> - saw-multiple, i.e. saw the contact use/communicate the key via these >> insecure but independent channels/mediums (e.g. via email, phone, IM from >> several accounts) >> 3. read some subjective comment/advice about how "safe" the current >> situation is >> 4. set the *overall policy* for letting other applications treat a contact >> as "valid". e.g. require-full, require-friend-trust, allow-but-warn-if-new >> (i.e. a form of TOFU) >> 5. perform physical verification via technical means, such as scanning a QR >> code >> 6. sync this state to other trusted devices >> >> The point being that identity/key verification is a logistics and usability >> issue, and not really a cryptographic issue. >> >> It is semi-relevant to the other thread - we want to support not only fpr >> verification, but other methods of verification too, including "soft" >> verification (inc. the effortless TOFU) that is easier but not secure >> against Nation-State-Adversaries. >> >> Advantages: >> - user can set strict/loose verification policy based on their own >> preference, in one single place, that affects all applications >> - saves application writers from having to think about these issues >> - unified UI for verification >> - synced between different devices. most crypto-application writers will not >> bother with this, it is too hard and a separate concern from their program. >> >> Disadvantages: >> - the component's verification-status data-model may not cover everything >> that a certain application needs. this can be fixed with time, however, and >> it will eventually benefit all applications, not just a single one. >> - most developers of contact managers aren't security-trained. you would >> hope that developers of keyrings are a bit better, but we still see things >> like http://gaganpreet.in/blog/2013/07/24/kwallet-security-analysis/ >> mistaking EBC for CBC >> >> Thoughts? >> >> X >> >> -- >> GPG: 4096R/1318EFAC5FBBDBCE >> git://github.com/infinity0/pubkeys.git >> >> >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging >> -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
