Add functions to encrypt and decrypt messages without signing or verifying them

[ameba23]

This addresses: #13

This adds a struct EncryptedMessage, which is identical to SignedMessage except for that it does not include a signature or the author's public signing key.

Wasm bindings encryptOnly and decryptOnly are also provided.

The idea is to use this in Entropy for public key visibility where we do not want to restrict which messages are signed by the network based on the identity of the requester.

However i think there are reasons why we might anyway want to sign these requests, even if it is only with an ephemeral keypair:

• We currently use the account ID of the requester together with the message hash as a session ID, so nodes can know which protocol session they are joining when they connect to each other. If we use only the message hash, and two people try to sign the same message around the same time, only one of them will get a signature, as the second requester will clobber the first one's protocol session.
• When receiving a signature request, we don't know whether it will be a SignedMessage or an EncryptedMessage until we know what the key visibility is. So we will have to attempt to parse JSON as a SignedMessage and if that fails attempt to parse as an EncryptedMessage. I think this complicates things a bit.

So i am not sure this PR is a good idea.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
x25519-chacha20poly1305	✅ Ready (Inspect)	Visit Preview	Oct 25, 2023 7:50am

[JesseAbram]

I think in this case looking at core if in this scenerio we keep the Signed message type but for the Signature we put in a null signature or junk data this will be fine as core will still have all the necessary fields but on public it will ignore the sig field all together

[JesseAbram]

this shouldn't have a sk though?

[ameba23]

The secret key is used to derive an encryption keypair. We could omit this argument and generate an ephemeral one internally.

But i think if doing that, we may as well also sign the message with it and not have to have an EncryptedMessage type.

Personally i think the best solution is to close this PR, and create an ephemeral signing keypair on entropy-js when making a request, so that the signature request each node receives can be checked they come from the same source, even if the keypair is only used for that particular message.

[JesseAbram]

ya we can do that, should be simple enough and we can use that account ID in the session ID all solutions handled

[JesseAbram]

but we would need to make a function that allows for the account to be passed in rather then derived from the sk

[JesseAbram]

• We currently use the account ID of the requester together with the message hash as a session ID, so nodes can know which protocol session they are joining when they connect to each other. If we use only the message hash, and two people try to sign the same message around the same time, only one of them will get a signature, as the second requester will clobber the first one's protocol session.

• this one should be an easy fix we create a more unique way to make a session ID

• When receiving a signature request, we don't know whether it will be a SignedMessage or an EncryptedMessage until we know what the key visibility is. So we will have to attempt to parse JSON as a SignedMessage and if that fails attempt to parse as an EncryptedMessage. I think this complicates things a bit.

• so here we check the key visibility before we check that it requires a sig
  https://github.com/entropyxyz/entropy-core/blob/master/crates/threshold-signature-server/src/user/api.rs#L139

[JesseAbram]

just checked with session ID that is already the case https://github.com/entropyxyz/entropy-core/blob/master/crates/threshold-signature-server/src/user/api.rs#L198

so we just need one function that allows a client to set the account different from the sk (as new does not do that) and then use it when we have public accounts on the client side (sdk)

[ameba23]

just checked with session ID that is already the case https://github.com/entropyxyz/entropy-core/blob/master/crates/threshold-signature-server/src/user/api.rs#L198

so we just need one function that allows a client to set the account different from the sk (as new does not do that) and then use it when we have public accounts on the client side (sdk)

I'm not budging on this one - i think we should generate an ephemeral secret key from within the SDK and leave things here as they are.

In my understanding - the signature request account is whatever account is requesting a signature, which in the public case can be anyone, including a short lived keypair generated just for a single set of signature requests.

If we want to be able to indicate which entropy account should be associated with the signature request, i think that should be done with a field on UserSignatureRequest in entropy-core.

This relates to entropyxyz/entropy-core#484 - i think keyshares should not be stored under the signature request account, but either the program modification account, or the public verification key.

If we let people set an arbitrary account ID here to cater for public programs, well run into problems when we try to implement permissioned programs - as for permissioned we need to know both the author of the request and what entropy account they are requesting to sign with.