Design encryption/authentication

[conradoplg]

Write up design choices for #179

I'll try to write it up here in this issue to avoid having another random google doc

Assumptions

(Everything is up to discussion, feel free to chime in on those)

Each participant will have a key pair and all participants have each other's public key in an address book of sorts.

In practice this can be done with registering pubkeys in the server, and then validating pubkey fingerprints.
Later in full P2P setting this can be done similarly, broadcasting pubkeys and validating fingeprints.

For simplicity I'll assume 1 participant = 1 pubkey. If someone has two devices with two different shares, they will need to register two users.

Option 1: One-way Noise protocol

Use the Noise X pattern

(X and not K because with X is easier to determine who the sender is from the sent public key; with K the receiver would need to try to decrypt with all registered pubkeys until one is successfull. But of course it shouldn't simply trust the sent key but rather try to match it to a contact in the user's address book)

Upsides:

• Simple, no handshake required

Downsides:

• May not fulfill security requirements:
  • Source security: vulnerable to key-compromise impersonation (KCI) ("If the recipient's long-term private key has been compromised, this authentication can be forged")
  • Destination security: forward secrecy for sender compromise only, vulnerable to replay ("If the recipient's static private key is compromised, even at a later date, this payload can be decrypted. This message can also be replayed, since there's no ephemeral contribution from the recipient.")

Option 2: Two-way Noise protocol

Use the Noise_XK pattern.

Same comment about pubkey being sent applies.

Upsides:

• Better security properties
  • Source security: Sender authentication resistant to key-compromise impersonation (KCI).
  • Desination security: Encryption to a known recipient, strong forward secrecy.

Downsides:

• Requires a handshake, which will increase the amount of rounds required

Other alternatives

There may be other alternatives, possibly using digital signatures, but I want to first determine if one of those solutions is enough.

Security considerations

Key-compromise impersonation (KCI)

KCI would allow an attacker that hacks a recipient to impersonate any participant to them. For example, if the Coordinator is hacked and the comms private key is stolen, the attacker send a message to them pretending to be one of the participants. Or if a participant is hacked, the attacker could pretend to be the Coordinator.

The main implication for this is that cheater detection would be no longer accurate. FROST itself would remain secure since the FROST itself does not require authentication.

An argument for why this is not important in our scenario is that if e.g. the Coordinator is hacked and the comms private key is stolen, it is likely that an attacker will also have access to the entire Coordinator environment and could fiddle with their access book, also interfering with cheater detection.

Forward secrecy for sender compromise only

Having this would allow an attacker who hacks a participant and steals their comms private key to decrypt all previous messages they have received, if the attacker has previously captured them.

An argument for why this is not important in our scenario is that if a participant gets hacked and their comms private key is stolen, it is likely that an attacker will also have access to the entire participant's environment and could steal their Full Viewing Key, which would allow the attacker to obtain all transactions they have signed in the past. Thus having forward secrecy for sender would not let the attacker learn much more (with exception of messages/transactins that did not end up being signed and published, but that does not seem to be critical).

Replay vulnerability

Having this would allow a passive attacker who can listen to comms between participant to replay a message. I believe this would not break FROST, and would not work in practice because the server uses session IDs for each signing session, and replaying a message would just make the server ignore it because it is not attached to a valid session (or would not make sense if the session is still running).

Non-repudiation

I believe that for a totally effective cheater detection, we would need some form of non-repudiation (which none of those options provide), which could take form of simply signing messages, taking care to include the recipient identifier to beat surreptitious forwarding.

However it feels like this is overdoing it, and cheater detection is OK in a best-effort basis for our use case of Zcash transactions.

Conclusion

Considering those security considerations, I'm favoring the simplest option of using One-way Noise. We should add a protocol version to messages so that we can upgrade the protocol if we decide we need higher levels of security.

An argument for using Two-way is security in depth, and the the additional rounds do not matter that much in practice.

[mpguerra]

The design work for this issue is done