Predicate attack against current DEAP impl

[sinui0]

I just realized there is an predicate attack against our current DEAP impl we overlooked which doesn't require malicious garbling or OT to perform.

The Follower simply has to choose different inputs for each execution. This depends on the function in question but generally the follower can select different inputs such that:

f(x_0, y) \neq f(x_1, y) \longleftrightarrow g(y) = true

where $x$ and $y$ are the Follower and Leader inputs respectively. This leaks an arbitrary predicate of $y$ which satisfies this.

This attack is also present in standard Dual-ex, but we overlooked mitigating it. Fortunately the mitigation is relatively simple (but will require some work).

We need to implement the CommittedReceiver counter-part to our CommittedSender impl. Then during DEAP finalization, we can check that the Follower provided the same inputs to both executions by validating their OT choices.

It's still not clear whether this is something we need to mitigate for our application, the Followers only input is the PMS share to the PRF and it seems that it would be infeasible to select a predicate that affects the AES-CTR circuit.

[themighty1]

I agree that a fix is needed. Will make the protocol easier to reason about if both inputs are checked to be equal.

[themighty1]

the Followers only input is the PMS share to the PRF

right. And with this attack the Follower could learn 1-bit info about the Leader's PMS share which is acceptable for us.

and it seems that it would be infeasible to select a predicate that affects the AES-CTR circuit

it should be impossible to attack encryption/decryption circuits because the Follower is "locked" into only using the labels corresponding to his key share (these are the labels which were derived during TLS handshake key derivation).

Apparently this attack does not apply to the way we impl tlsn.

Do you agree with the above @sinui0 ?

[sinui0]

it should be impossible to attack encryption/decryption circuits because the Follower is "locked" into only using the labels corresponding to his key share (these are the labels which were derived during TLS handshake key derivation).

Apparently this attack does not apply to the way we impl tlsn.

Do you agree with the above @sinui0 ?

I do agree, I don't think this is a practical attack against TLSN