Saltpack Questions and Thoughts

Hey

From the specs:

Repudiability. It's possible for Bob to forge a message that appears to be from Alice. That means that if Bob reveals Alice's message, Alice can deny that she sent it.

It should be clarified that this is only true for a one-to-one encryption with only one recipient.
As far as I understood, the repudiability comes from the fact, that this encryption ...

9 For each recipient, encrypt 32 zero bytes using crypto_box with the recipient's public key, the sender's long-term private key, and the first 24 bytes of the header hash from #8 as a nonce. Take the last 32 bytes of each box. These are the MAC keys.

... is equivalent to the encryption using the recipients private key and the senders public key
With multiple recipients, one would need all private keys to fork a message.
In the case of keybase.io, that would mean all own private device keys and all private keys of all other recipients.

The other thought: I think the payload key crypto_boxes order should be explicitly randomized. That would improve forkability and impede investigations. The used order of the recipients and their devices may depend on the time-grown storage structure of the client software. Sorting after public or private keys is not a good idea, since someone who wants to create a fork does not have that information.

Start by reviewing the Saltpack specification sections quoted in the issue and the surrounding design discussion. No source files or tests are identified; done means reaching a maintainer-backed decision on the repudiability wording and whether payload key crypto_box ordering needs an explicit specification change.