the deniability we could not have with signatures

There is a property we wanted and could not have, and the useful thing is to say so precisely. In a conversation between two people, deniability means neither participant can later prove to a third party that the other took part — not that the evidence is hard to read, but that no transferable proof exists at all.

Our authentication is built on signatures. A signature is exactly a transferable proof: anyone can verify it, it is bound to the message, and it survives being copied into another context. That is the property that makes it useful for identity, and it is the same property that makes deniability impossible while it sits in the transcript. The designs that do achieve deniability get there by deriving the session secret from material either party could have computed alone, so each of them could have fabricated the whole exchange. A signature cannot be fabricated by the party who did not make it.

We wrote the gap down instead of arguing around it: what we have, what the alternative costs, and what a migration would require. The honest version of the claim is that our identity layer buys verifiability at the price of non-repudiation, and that swapping the authentication mechanism yields a different product with different guarantees, not a configuration change.

The related finding was smaller and equally useful. The standard key-encapsulation interface underneath does not implicitly authenticate the sender, so the signature is doing work that cannot be delegated to the key exchange alone. Recording both limits is what makes the rest of the design's claims legible.