On 08/17/2016 02:17 PM, Ximin Luo wrote: > Hi Ian, could you elaborate both on the /current status/ and the > /meaning/ of the above? > > (Yes, I was at the meeting, but missed the start where you might have > properly explained this, and this e-mail doesn't contain the details.) > > What needs to be done by your student? The CCS paper, linked above, > seems to be relatively complete and not missing any key holes. But I > just I spoke to David and he seems to believe that we're all still > waiting on something important from your student.
Hello, I am the student in question. We expect to post a tech report, which describes various improvements to RSDAKE/Spawn, and introduces a new variant called "QuickSpawn", to the list in O(days). We just have a few last-minute additions to make after some discussion at PETS / SPW2016. The changes that the tech report makes compared to the CCS'15 paper are: - For performance, we use the ROM instead of the standard model (no more pairings required!) - Concrete description of a fast ROM-based dual-receiver cryptosystem - We use zero-knowledge proofs instead of ring signatures - Full algebraic descriptions of RSDAKE and Spawn with the new primitives - Spawn is made contributory (the CCS version is non-contributory) - QuickSpawn - This DAKE is similar to Spawn, but should only be used non-interactively - Like non-interactive Spawn, QuickSpawn does not provide online deniability for informing responders (only for informing initiators) - QuickSpawn requires only a single zero-knowledge proof (no public-key encryption, no dual-receiver encryption) - QuickSpawn is extremely efficient in terms of computation and network overhead; it is faster and smaller than RSDAKE (and *much* faster and smaller than Spawn) and is comparable to 3-DH - We discuss key compromise impersonation attacks, how they relate to online deniability, how vulnerability to these attacks can actually be beneficial from a deniability perspective, and how to apply our DAKEs so that users get deniability without necessarily making themselves vulnerable - A hybrid approach for RSDAKE/Spawn/QuickSpawn that provides post-quantum forward secrecy (i.e., if quantum computers appear, past key exchanges cannot be broken retroactively, but we need to stop using the protocol and start using post-quantum authentication) ~ Nik _______________________________________________ OTR-dev mailing list OTR-dev@lists.cypherpunks.ca http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
