RecPedPop: use ECDH between hostkeys to drop the enckeys round

[jonasnick]

This would save a round in RecPedPop but uses the static host keys for ECDH instead of ephemeral "enckeys".

Will adjust the names of the rounds, etc. accordingly later.

[real-or-random]

Concept ACK (or I mean, feel free to merge, we can do the remaining changes on master if this is more convenient)

I think the crucial thing here is that this changes the interface of EncPedPop. But I think it's totally fine. A caller that just has a seed can always use it to derive a deckey and feed that one into EncPedPop.

[real-or-random]

:)

[real-or-random]

I'm rather convinced that it's okay. Malleability of public keys is not an issue for signatures. I remember that we discussed this a lot for BIP340 (where we even mention that dropping the first byte is an option, to reuse BIP32). Even if you look at this as a modified signature scheme that takes 33-bytes keys as input, this scheme is still SUF-CMA.

We need to be careful about malleability if we start to use the shortened pubkeys in other places, e.g., when we hash them. But your draft PR doesn't even do this.

But yeah, I agree it's not exactly elegant. We could also use x-only ECDH (bitcoin-core/secp256k1#1198), and this will be cleaner and faster. Or in principle also EllSwift, but that's a bit odd here because it doubles the key sizes.

[jonasnick]

The downside of x-only ECDH is that it increases the complexity of the spec. Another option is ECDH with lift_x(xonly_pubkey), but that requires negating the seckey when seckey*G has an odd y coordinate.

[real-or-random]

We should perhaps add a paragraph or a footnote that explains why a static-static ECDH is okay here. People's first impression may be that static DH is scary and from the 90s. The usual suspects are replay attacks, lack of forward security, and key compromise impersonation. Hm... now that I've listed all of these, let's maybe wait another day and think about it.

[real-or-random]

Okay, so key compromise impersonation (KCI) deserves some thoughts.

What's a KCI attack? Say Alice and Barbara perform a key exchange. If the attacker has Alice's secret key a, it's not surprising that he can impersonate Alice to Barbara. But in the case of static DH, he can also impersonate every Barbara to Alice: since he knows a, he can derive the shared secret aB for any other public key B.

In our setting, this would be a rather devastating attack. Alice may have checked all other public keys out of band, but the attacker can impersonate every other participant in the DKG, pairing her only with malicious sock puppets.

Note that the (perhaps) surprising part here is only authenticity. The attacker can send messages that look like they came from Barbara. Confidentiality is not specially affected by KCI attacks. While it's true that the attacker can also eavesdrop on every connection between Alice and honest Barbaras, that seems impossible to avoid if the attacker has a (and if we want to avoid ephemeral keys to facilitate backups.)

One way to prevent this attack is to add signatures that bind the public key to some unique session ID. (That's why signed ephemeral DH is, in general, not vulnerable to KCI: the ephemeral keys act as a session ID) In the case of RecPedPop, this means that the attacker can impersonate everyone to Alice and complete the key exchanges. But at the end of the protocol, he simply won't be able to sign the transcript as any Barbara.

We don't have the signatures in pure EncPedPop. But even here, the equality check protocol should detect if the attacker tampered with the messages sent to Alice. (And confidentiality is anyway lost, as mentioned above.) This is what meant when we wrote earlier in the document that EncPedPop is authenticated via the equality check.

[jonasnick]

A KCI attack does seem like a problem indeed for DKG. Or the other way around, it is a really desirable property that if the adversary only compromises the seed (and not the machine the DKG is running on), they can not compromise future setups, i.e., any coins sent to an address that is output of a DKG is still protected by a t-of-n (although one signer is already compromised).

The applicability of the KCI attack seems to not be affected by this PR because an attacker compromising a seed would be able to derive the secret my_deckey allowing just the same impersonation attack on master.

However, I'm not quite sure if you suggest that KCI is a real problem on master or in this PR: the attacker can decrypt shares sent by the victim and inject valid shares, but they won't be able to produce a signature for the impersonated participants in certifying_eq which prevents the victims from accepting the outputs of the DKG.

[real-or-random]

The applicability of the KCI attack seems to not be affected by this PR because an attacker compromising a seed would be able to derive the secret my_deckey allowing just the same impersonation attack on master.

Indeed, the same occurred to me after I had written my previous comment.

However, I'm not quite sure if you suggest that KCI is a real problem on master or in this PR: the attacker can decrypt shares sent by the victim and inject valid shares, but they won't be able to produce a signature for the impersonated participants in certifying_eq which prevents the victims from accepting the outputs of the DKG.

What I was trying to say is that the signature in certifying_eq definitively exclude KCI attacks against RecPedPop. (As any "end-to-end" Eq should exclude them for EncPedPop.)