Suppose Alice meets Bob in-person at a meeting or party, for example, and let me try to channel Alice’s potential thought process: “Hmmm, Bob seems interested in that topic that might make him a good potential member for this sensitive group I’m in… But I just met him and don’t know him very well yet I wonder if I should hold off on inviting him and first ask around to see if anyone else knows anything good or bad about him? Oh crap, no, if I do that then Autocrypt is going to insist that I re-run that device connect rigmarole and re-verify him later once I decide to invite him to the group, and by then I’ll be back in Foozloo. In fact, the current rolled-together process seems like it’s optimized for, and perhaps even incentivizes, the less-secure behavior of inviting people to sensitive groups on first meeting them.
If Alice and Bob are longtime friends, which I expect and hope will be the common case especially for the most sensitive verified groups, then it seems more likely that Alice and Bob will likely already have a relationship verified via person-to-person secure connect (section 2.1), and just want to reuse or refer to that when one of them wants to invite the other to join a verified group.
Autocrypt paper verification#
As currently designed, the protocol seems to make it fundamentally necessary for Alice and Bob go through the rigmarole of person-to-person device verification each time Alice wants to invite Bob to a new verified group or vice versa.
In general, I’m not seeing why it’s either necessary or desirable to “roll together” the pairwise (Alice-Bob) verification workflow with the verified group-join protocol, instead of making them properly-linked but separate activities. Messages sorted by: Ĭontinuing feedback regarding the section 2.2 Verified Group Protocol:.Next message: Cwtch: Privacy Preserving Infrastructure for Asynchronous, Decentralized, Multi-Party, and Metadata Resistant Applications.
0 kommentar(er)
