[OTR-dev] IFF meeting notes - OTRv4

[Nik Unger]

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