On 17 June 2014 18:38, Daniel Kahn Gillmor <[email protected]> wrote: > I suspect the rationale for OTR having this behavior was an attempt to > cope with the situation of one user connecting with different pieces of > client software (possibly on different machines), not all of which would > have access to the same OTR keys. This would produce a lot of false > alerts under the proposed scheme. > > ... > > OTOH, i think that the common OTR implementation is designed > specifically to avoid sharing keys between systems, since you only need > one copy of the key to be compromised in order to lose OTR's > communications security guarantees on every agent. I'm not convinced > the OTR team made the right tradeoff there.
I've been mulling over an idea in my head for a protocol built on top of OTR, specifically designed to mitigate the metadata and contact list problems while emulating the (extremely useful) feature of GChat that lets chats follow you between devices. To address the latter it'd make use of a OpenPGP Subkey-like system. For people who run their own server, you would authenticate to your daemon, and it would issue signatures for your current key & address, saying "This is really Tom Ritter", and if the remote client trusted Tom Ritter, their UI would afford the same level of trust to this brand new key on this brand new account it never saw before. -tom _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
