Diffie-Hellman over Katzenpost

[Valodim]

For consideration / discussion:

The mixnet model of Katzenpost is based on providers, and mixes messages in a "client-to-provider" fashion. To achieve confidentiality of a mixed message from the receiving provider, an additional layer of encryption between clients (end to end) is required.

This design of client-to-provider mixing yields an interesting, asymmetric way of communication. In particular, a MitM attack on a simple (unverified) Diffie-Hellman session requires corroboration of the providers of both participants, since each provider cannot intercept the outgoing messages of its user.

Consider this scenario, given the above key service infrastructure, and an honest provider P and dishonest provider N:

• A@P requests B@N's identity IB from +K@N
• +K@N replies with a fake identity key IB'
• A@P creates a Diffie-Hellman session between IA and IB' as DHAB'
• A@P sends message M, encrypted with DHAB as M', to B@N
• N receives M', re-encrypts it to M'' with a new session DHA'B
• B@N receives M'', and decrypts it from DHA'B
• B@N answers M2 to A@P, encrypted as M2' using DHA'B session
• N cannot intercept M2', since its route is chosen by B@N!
• A@P receives M2', can't decrypt -> failure

What I think this means in practice is that we get much better end-to-end properties in an unverified session than any nonmixed/centralized service.

(this is not really an issue, per se, but it has shown to be a thing worth discussing in the more general context of "how are we going to e2e" on top of katzenpost)

Related #31

[Yawning]

As part of the specification (and implemented in minclient/block), a method for client to client encryption is provided based around Noise's X pattern (http://noiseprotocol.org/noise.html#one-way-patterns).

X(s, rs):
  <- s
  ...
  -> e, es, s, ss

Intercepting messages requires that Bob has a false view of Alice's public key (because Bob will compare the s sent over the wire to the known value obtained a-priori) and that Alice has a false view of Bob's public key (because Alice has to encrypt to it).

[david415]

sounds like you two are talking past each other... both bringing useful observations to the table. ;-p