Hi Marcela, Thanks so much for the quick reply!
> I'm assuming you mean Alice is the user with the strict key change policy in > this example? So yes, Alice's client would see the strict flag set as part of > Alice's user metadata and would know to cache Bob's key and only accept a new > one if the key change is authenticated with the cached key. Well, I meant that Bob has the strict policy set, and that Alice sees that and therefore only accepts a new key from Bob if it’s signed by his previous key. But your answer seems to also apply to Bob? > Right, the specification of the key change protocol was actually a follow-up > project I worked on with an undergraduate, who wrote his junior research > paper on it. He also implemented this protocol, and getting it merged into > our reference implementation on GitHub is in the works. In the meantime, I > can get his junior paper on the CONIKS website. Yes that would be great, I'd very much like to read that. :-) > There is, you can sign up at coniks.cs.princeton.edu Thanks! I’ve signed up! ^_^ Cheers, Greg > On Mar 21, 2016, at 11:35 PM, Marcela S. Melara <[email protected]> > wrote: > > Hi Greg > >> On Mar 21, 2016, at 22:56, Tao Effect <[email protected]> wrote: >> >> Dear list, >> >> Questions for Joseph, Marcela, or any other CONIKS experts out there: >> >> Regarding the strict key change policy mentioned in the paper, how can Alice >> verify Bob’s latest key? Does she cache his previous key and verify the >> latest one received comes with a key-change message that’s signed by the >> previously cached key? > > I'm assuming you mean Alice is the user with the strict key change policy in > this example? So yes, Alice's client would see the strict flag set as part of > Alice's user metadata and would know to cache Bob's key and only accept a new > one if the key change is authenticated with the cached key. > >> This aspect doesn't seem to be part of the protocol described in the paper. >> If there is a way to securely verify the key change using a previously >> verified/pinned key then this mechanism could prevent MITM attacks. >> So is this specified in an “official protocol” somewhere? > > Right, the specification of the key change protocol was actually a follow-up > project I worked on with an undergraduate, who wrote his junior research > paper on it. He also implemented this protocol, and getting it merged into > our reference implementation on GitHub is in the works. In the meantime, I > can get his junior paper on the CONIKS website. > >> Also, is there an official discussion list for CONIKS? > > There is, you can sign up at coniks.cs.princeton.edu > >> >> Thanks much! >> Greg >> _______________________________________________ >> Messaging mailing list >> [email protected] >> https://moderncrypto.org/mailman/listinfo/messaging
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
