Sign every change

[nikgraf]

Every change should also be signed with the private signature key of the user.

Before applying changes the signature must be verified.

[pcarranzav]

As far as I can tell the main place this is missing is in RequestCreateUpdate right? So we could add an author field to the Updates type and then verify it when applying each update. Is that what you had in mind, or am I missing other places where we're not signing?

[nikgraf]

spot on! I was thinking:

const nonceAndCiphertext = Messages.encryptMessage({
  message: lastLocalChange,
  secretKey: Utils.hexToBytes(space.keys[0].key),
});

// pseudo code
const signature = sign(nonceAndCiphertext, signaturePrivateKey)

const messageToSend: Messages.RequestCreateUpdate = {
  type: 'create-update',
  ephemeralId,
  update: nonceAndCiphertext,
  signature,
  spaceId: space.id,
};

When we send it the author doesn't have to be sent along, but when receiving updates the sever should send the author along.
Not sure if we want the accountId or signaturePublicKey. Maybe the accountId and then we can find the signaturePublicKey in the local state. It's more of a question what our main identifier for an account is?

The server probably also should verify the that the signature is correct to avoid relaying invalid messages.

What do you think?

[pcarranzav]

I think this makes sense, but I think it would be better to include the spaceId and ephemeralId in the signature to prevent replay attacks or trying to send the same update on a different space.

I think we should use accountId as the main account identifier everywhere, but the client needs to know what public key was used to sign (unless it can be recovered from the signature itself?) in case there are many keys for each user. So imo we either:

• send both accountId and signaturePublicKey in the updates. In this case the client can check if the accountId and key are in the local list of identities or fetch it from the server and verify the identity proof. Or,
• send only signaturePublicKey but also re-introduce the /identity/by-public-key endpoint. Then if the key doesn't have an accountId in the local list of identities, the client can fetch it from the server and verify the identity proof.

Wdyt?

[nikgraf]

Let's separate it into two topics :)

Context on every Update

Do we want to add it to the AAD (additional authenticated data) of the encryption, only the signature or both? I think both would be the safest, but just on the signature would be good enough afaik

Adding the spaceId makes sense to me. What is the ephemeralId? Is it randomly generated or a counter? How does it prevent replay attacks?

User Identification

Only relying on the accountId sounds reasonable. So as a first step we can clean up SpaceMember since it includes signaturePublicKey & encryptionPublicKey. But when reconstructing the space event chain locally we can extend the message with the necessary signatures to combine them and store the locally. This way we don't need an extra endpoint and any update that is based on a known state of the space event chain must be an accountId that is known. In case we receive an update that is referencing a newer space event we first must resolve it. Otherwise we don't even know if the account that sent it is still a valid member of the space.

I think this could work. What do you think?

[nikgraf]

Synced with Pablo:

Conclusion: Context on every Update

We include accountId and ephemeralId only in the signature.

Conclusion: User Identification

We use the accountId is primary identifier.
Note: we can recover the publicKey from a signature when using secp256k1. So we don't need to keep publicKeys around.