Add symmetric capabilities to DecryptedThing

[benjaminpreiss]

#213

[marcus-pousette]

I wonder whether the Keychain should be improved to also be able to export Ephemeral keys based on their hashes or something

But this is about solving the problem

• How do I know I have decrypted something correctly?
• How do I know that I can decrypt it before decrypting it? (Lets say I have 1000 ephemeral keys in the keystore, I can not test all of them)

[benjaminpreiss]

Interesting thought... So that means one would also include an Envelope within EncryptedSymmetricThing that includes the hash of the SymmetricKey (salted)?

[benjaminpreiss]

... Well maybe the naming would not be envelope any more as there is no signature.

[benjaminpreiss]

Regarding your questions:

How do I know I have decrypted something correctly?

I think certainty can be provided by successful deserialization?

How do I know that I can decrypt it before decrypting it? (Lets say I have 1000 ephemeral keys in the keystore, I can not test all of them)

When we include the hash of the ephemeral key used for encryption in the "envelope", we have a linear lookup time for the question "Can I decrypt?".

[marcus-pousette]

I think certainty can be provided by successful deserialization?

There might be scenarios where the decrypted ciphertext still can deserialize succesfully into your object even though the decryption is invalid. Lets say it is not something you can trust on 100%

But this page is pretty good

https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox

(which is the function you are using in this PR)

So the solution you have there does the integrity check. I think it bundles some authentication data in the cipher text that depends on the nonce and the secret key used. So that issue would be solved (but one has to test) that this will be sufficient for the verifying it has been decrypted correctly.

When we include the hash of the ephemeral key used for encryption in the "envelope", we have a linear lookup time for the question "Can I decrypt?".

That would be an easy way to go about it. But it is not standard thing to do it seems.. (I am lookig around on the web and ask the chatbot). But it feels very intuitive

An alternative thing would be that this is on the app level. So you would a have a keychain locally which is a KV store, and you would put your symmetric keys in there with well chosen IDs, like it could be the db address of the store you want to encrypt. So basically when you want to decrypt a db you would go into this keychain and look for this key that has an id which is the db address and then if it exist, use it to decrypt entries.

Another alternative would be that you would have a shared keychain which is a document store for ephemeral keys which is encrypted with publickey encryption (the encryption you get default with the document store now). With that you can have each document to have an id which you somehow connect with the id you use for the messages you encrypt in another db (this solution would also help you send your ephemeral keys to the other party)

[marcus-pousette]

When the recipient for some unknown reason only knows the symm key, he cannot sufficiently answer that question in this scenario.

So what I want to continue to say on this topic is that if you want to receiver to have all necessary data to lookup the secretkey from the keystore you practically need to talk on the sidechannel for every message (?) (given that the salt is unique for every message). If you are to talk about the encryption for about every message you might just want to generate a new symmetric key for every message altogether and use the sidechannel to send that over instead.

Using salts is generally done with a slow hashfunction for passwords which have a low entropy. This prevents someone from bruteforcing passwords given that they know they salt and the password + salt hash. But in this case the "password" is high entropy and there is no possibility that an actor will try to generate all 32 byte symmetric keys to match the hash. The only thing would be that if the symmetric key gets lost, then a middle man could have a easy way of figuring out what messages the middle man can decrypt. Having a salt here would not help anything, or making anything harder if the secret key gets lost. For the same reason as the salt for a password db does not help anything if the password in plain text gets lost

The question remains - what can we do?

i would just keep it simple!

HashedKeyEnvelope

just make it

{ hash: Uint8Array } 

Pros:

• Will solve a problem where you want to have encryption but share keys on a sidechannel instead of inside the message itself (i.e. use the PublicKeyEnvelope)

• The hash will help a receiver to figure out if they have a key in the keystore

• Noone can find out what the symmetric key is given the hash

• I can loop over all messages efficiently and figure out what messages I can decrypt, if not I can use a sidechannel to ask for the symmetric key by refering to its hash

Cons:

• Someone from the outside can fiigure out that all messages are encrypted with the same key (make this a less of a con by generating new symmetric keys at a frequent rate)

[benjaminpreiss]

Agreed! That's how I will implement it.

[benjaminpreiss]

Would you then also just keep one EncryptedThing or split up in EncryptedThing and SymmetricEncryptedThing?

What type would you suggest for the unified EncryptedThing encrypt function?

async decrypt(
	keyResolver?: Keychain | X25519Keypair // | Uint8Array like this?
): Promise<DecryptedThing<T>>

[marcus-pousette]

Would you then also just keep one EncryptedThing or split up in EncryptedThing and SymmetricEncryptedThing?

What type would you suggest for the unified EncryptedThing encrypt function?

async decrypt(
	keyResolver?: Keychain | X25519Keypair // | Uint8Array like this?
): Promise<DecryptedThing<T>>

One encrypted thing, because later lets say the Keystore can both store Symmetric keys and X25519 Keypairs then you can do

await encryptedThing.decrypt(myKeystore) 

without knowing the details of what the Envelope is.

But there is a problem now with the Keystore class is that it depends on the libp2p Keystore object which only can store PeerIds.. and it will also be dropped soon

libp2p/js-libp2p#2084

[marcus-pousette]

There might be a sidequest to this to rework the Keychain to have following features

• Can store all keytypes necessary
• Can look them up by their IDs or by their PublicKeys or their secret key hashes

[marcus-pousette]

See #215 (comment)

Closing