Compatibility with Mithril

[CarlosLopezDeLara]

We need to find a way to co-exist with Mithril signer. The Mithril signer uses KES keys to sign a verification key, see https://mithril.network/doc/manual/operate/run-signer-node#mithril-signer-deployment-model

This signing happens at every epoch, and in the current design it directly accesses the KES.skey from disk.

To avoid Mithril signer having to deal with securely handling KES keyss obtained from KES-Agent, a potential solution is to include a signing service within KES-agent itself such that it can receive a request and a message (the mithril verificaiton key) and sign it.

This tikcet is about exploring feasibility of this solution as well as exploring alternatives.

[perturbing]

I think the best approach is to add a feature to the KES agent that allows it to communicate signatures over some predetermined data packet and run it alongside the Mithril node. The alternative, adding the feature of storing mlocked KES keys in the Mithril node, is more involved. Also, unlike a block producer node, the signing of this data for Mithril is sporadic (see point 3 here, the other two points are also important!). But @jpraynaud , can you confirm that these risks are okay? And to be more precise, it can happen that upon reboot of the machine that runs the mithril node + KES agent, a small delay in setup is perceived, as the KES agent has to retrieve the KES key from a backup kes agent.

So, regarding this integration, the implementation will change in two places: the kes-agent lib and the Mithril code. Where roughly

The KES-agent: The control socket api will need to be expanded to accommodate the bidirectional communication of this data.

The mithril code: This will need to connect to the socket and construct the correct data to forward. I believe this is the place where that should be done.

One thing in this design is crucial, and that is that this data packet to be signed is of a certain predetermined structure! This is so that the KES agent can perform some integrity check on it and prevent signing arbitrary data that might be of value outside the usage of the Mithril context. An obvious example of this is how the KES key is used in Cardano node to sign blocks. We want to prevent that these signatures are ever of value outside this context. @jpraynaud , can you specify what data is currently signed by the KES key in the Mithril node?

[jpraynaud]

@perturbing I can confirm that the Mithril signer can deal with a small delay e.g. when a KES agent is restarting 👍

Indeed, the idea is to create a new implementation of a KesSigner that connects to the KES agent and asks for signing some payload. I think that we can use the n2c local state query from the Pallas library (which may need to be slightly adapted) to support communications with the KES agent.

The Mithril signer needs to sign the following information:

• the bytes encoding of the Mithril verification key with proof of possession. This is already implemented
• the bytes encoding of the Mithril single signature. This is currently being implemented in the context of the CIP-0137

[perturbing]

@jpraynaud , a quick question: can I assume that this signature sigma is always a valid signature for the same vk in the proof of possesion check?

Also, do you need both signatures for the above bytes at the same time or one at a time?

[jpraynaud]

@perturbing, the 2 signatures are actually completely de correlated:

• the verification key is signed once per epoch
• the individual signature is signed every ~10 minutes (with a signing key which was registered 2 epochs earlier

[perturbing]

That is good to know, thanks!

When you say

with a signing key which was registered 2 epochs earlier

How do you handle boundaries where the kes key is rotated for the SingleSignature? The KES agent will delete a key once a new evolved.

Also, how backward compatible do these signatures need to be? Say that I propose to sign this message instead of the raw bytes of the above-linked code

signed bytes := H(context_{BLS_VK_and_PoP, BLS_signature_and_merkle_index} || raw bytes)

I ask because I want to make sure we can check on the KES agent side that we have proper domain separation in the data we sign (to prevent signing data that can be used elsewhere). What do you think of such a thing?

[jpraynaud]

How do you handle boundaries where the kes key is rotated for the SingleSignature? The KES agent will delete a key once a new evolved.

We use the value of the KES period at which the signature was created: this is enough to verify a KES signature that was created 2 epochs ago (the goal of the signature of the verification key with the KES key is to make sure that we are associating it with the correct pool id and stakes).

Also, how backward compatible do these signatures need to be?

We actually need to sign exactly the raw bytes produced by the to_bytes functions of either the single signature or verification key. Otherwise, this will create breaking changes. This probably means that you need to be able to parse the raw bytes in the KES agent and make sure that they are valid? If this is the case, we will have to be extra careful with backward compatibility.

[perturbing]

We actually need to sign exactly the raw bytes produced by the to_bytes functions of either the single signature or verification key. Otherwise, this will create breaking changes. This probably means that you need to be able to parse the raw bytes in the KES agent and make sure that they are valid? If this is the case, we will have to be extra careful with backward compatibility.

Am I correct that such changes would break the already created certificates? And given this, making such a change would be cumbersome for the already running protocol? Just trying to get a better view of the impact :)

This probably means that you need to be able to parse the raw bytes in the KES agent and make sure that they are valid?

Alternatively, indeed, as you say, I would need to make some checks on the bytes. Since both byte arrays should contain BLS points, checking these is an approach (among the PoP check). For the single signature, I can look at the end of it (as it is of variable size if I am correct) and read the BLS signature (a BLS point). I will make an assessment of this impact; that is, what are the odds you find a valid BLS VK + PoP or single signature that can be used elsewhere? My intuition is that this should be okay; I just want to be sure.

[jpraynaud]

Am I correct that such changes would break the already created certificates? And given this, making such a change would be cumbersome for the already running protocol? Just trying to get a better view of the impact :)

Definitely, as the signers and aggregators use the signature of the verification keys to create the Mithril key registration when signing/aggregating with information registered 2 epochs ago.

Alternatively, indeed, as you say, I would need to make some checks on the bytes. Since both byte arrays should contain BLS points, checking these is an approach (among the PoP check). For the single signature, I can look at the end of it (as it is of variable size if I am correct) and read the BLS signature (a BLS point). I will make an assessment of this impact; that is, what are the odds you find a valid BLS VK + PoP or single signature that can be used elsewhere? My intuition is that this should be okay; I just want to be sure.

Yes, this could work and it should be enough to make sure that a compliant payload is signed. However, there is still a high coupling between the Mithril signer and the KES agent in order to find the bytes that match a BLS verification key or a BLS signature.

Maybe we could send a structured request (encoded in e.g. cbor hex) to the KES agent with:

• the type of data we want to sign (Verification key or single signature)
• the raw bytes to be signed
• the range of raw bytes that need to be matched/verified

[perturbing]

@jpraynaud , can you confirm that Mithril follows the ietf draft for the PoP here (give or take a domain separation tag like "PoP")?

And given that Leios will also use PoP, it is perhaps wise to choose a different DST than such a general one!

[jpraynaud]

@jpraynaud , can you confirm that Mithril follows the ietf draft for the PoP here (give or take a domain separation tag like "PoP")?

And given that Leios will also use PoP, it is perhaps wise to choose a different DST than such a general one!

@perturbing we use "PoP" as a domain separation tag as stated in the research paper.

Here are the part of the code that use it:

• Declaration of the DST
• Creation of proof of possession
• Verification of the proof of possession

If we change it, that probably means a breaking change in the protocol that would require a new Mithril era so that all signers switch to the new DST at the same epoch (not a trivial update).

@curiecrypt and @pyrros what do you think about changing this DST?

[pyrros]

Anything that adds specificity would be safe to do as a change.