Callme Whatiwant <nejuc...@gmail.com> writes: > On Wed, Oct 23, 2013 at 8:26 AM, George Kadianakis <desnac...@riseup.net> > wrote: >> Here are some more notes about mpOTR that I refreshed today. >> >> Here are some properties that the mpOTR protocol should have. These >> were also mentioned in the mpOTR paper: >> >> - Confidentiality >> - Entity Autentication >> - Origin Authentication >> - Forward Secrecy >> - Deniability (Repudiation/Malleability) >> Do we want this? It would certainly be nice to have, but it makes >> things so much harder! >> - Transcript synchronisation >> - ... >> >> Here is a breakdown of an mpOTR session in phases: >> >> [Channel establishment] -> [Authentication] -> [Key exchange] -> >> [Communication phase] -> [Shutdown phase] >> >> At the moment, the [Authentication] and [Key exchange] phases are the >> ones that need the most attention from researchers. More details >> below. >> >> Phase breakdown: >> >> [Channel establishment] >> * Where a set of initial unauthenticated participants is selected and >> a channel between the participants is established. >> >> Notes: >> - I assume that the protocol is centralized since it makes >> everything much easier (I assume that broadcast happens by >> sending a broadcast msg to a server). We can decentralize >> later. >> >> Solutions: >> - Assuming an application-agnostic protocol, this can happen using IRC >> channels, or XMPP MUCs, or SIP or whatever. >> >> [Authentication] >> * Where participants authenticate each other and a set of >> authenticated participants is established. >> >> Notes: >> - At the end of this phase, each participant should be confident >> that he trusts all the other authenticated participants. > > I'm not sure what this actually means. Can we rephrase it to be more > specific? > > The only protocols I know of that "should make me confident that I > trust another participant" involve tweaking my body chemistry or > neural function. > > Do you mean to say at the end of this phase, a participant has some > session state (such as a shared pairwise secret) which is > authenticated to another party's public key? Do you mean something > else? >
Hi, I meant that at the end of that phase, a participant X should be confident that participant Y controls the private key that corresponds to the public key that X had assigned to him in the past. This is the same authentication logic as in OTR. Ideally, each participant X should authenticate in this manner all the other participants (There are protocols which only authenticate the adjacent participants of X and assume that all participants are authenticated in a cyclic fashion). BTW, I did not try to make my post cryptographically robust. I just explained some concepts with words. On purpose, I did not expand on what happens when X has not assigned a public key to Y. Or whether mpOTR should have other authentication methods except public-key-based (for example, in OTR there is SMP). _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
