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.
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. -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 > _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
