search

uport-project / specs

uPort Protocol Specs
Apache License 2.0
86 stars 24 forks source link

Spec out message encryption #19

Closed pelle closed 6 years ago

coder5876 commented 6 years ago

This is interesting! I didn't know about the crypto_box_seal() function, which basically packages up the steps of creating an ephemeral key pair to use with crypto_box. It is interesting how then the nonce is derived from the ephemeral public key also.

I think we should have some kind of versioning here because we will most likely need to modify this encryption format once we define the encryption layer in DIF and W3C CCG. If we just say "if it's base64 then that means it uses vanilla crypto_box_seal()" we might not be able to upgrade easily.

Also we should make sure that we are compatible with the work being done in this MetaMask PR that adds encryption as a web3 layer. So that would mean either implementing crypto_box_seal in that PR, or modifying this one to be closer to the work there. I'm intrigued by the idea of deriving the nonce from the ephemeral pub key but that also adds complexity.

Agree with @oed regarding the need for padding. Without padding we will leak a lot of data about the payload. Not sure how to choose padding, is that something that the JWE spec deals with?

pelle commented 6 years ago

@oed @christianlundkvist about padding. I'm looking at approaches.

For padding value use space, \0 or other non base64 character

block size could be 64 bytes? But I'm open to suggestions.

Opinion?

This is what lib sodium does: https://download.libsodium.org/doc/helpers/padding.html

coder5876 commented 6 years ago

Ok, I think this looks good! One thing here that I think we should explicitly note is we are specifically encrypting base64-encoded data in this specific use case, which is why we can pick padding data that will not be confused with message data.

I'm now thinking that padding should probably not be included in the encryption ERC since we should be able to encrypt any type of data, which makes it not really possible to know which padding data would be ok to use.

coder5876 commented 6 years ago

I also think we should make sure we are flexible in our decryption in case we want to change the padding length later (we can make sure to always strip all padding \0 no matter how much it is)