Privacy issues about spec HOT 6 CLOSED

We've been working on shortening the info in Color_Def for a while. Both to allow for IND-CPA encryption and to have more entropy (i.e. bigger K and J). We will follow up with a new issue about that.

from spec.

The structure Color_Def will be encrypted, so it is not public

from spec.

We assumed only J would have been encrypted with K. In this case, we see other problems: using 12-byte K to XOR-encrypt a 32-byte string is dangerous. In fact, for instance, XOR-encrypting the version byte, which will be 0 for a long time, will disclose the first byte of K. More generally, using XOR where the key is smaller than the plaintext is not considered safe. However, using a IND-CPA symmetric algorithm would result in an encrypted Color_Def greater than 256 bits.

from spec.

I noted this problem too, XOR encryption is not an option.
I think we could use XXTEA, it has only 1 byte of overhead and the output size is a multiple of 4 bytes

from spec.

XOR encryption was never an option but just an example.
I am closing this since there is already an answer and opening discussion about the best encryption for Color_Def here #5
please @the9ull comment why XXTEA is a good choice there.
@fedsten could we have a cyphertext of 32 bytes with IND-CPA if we drop some data from the Color_Def data (for example dropping the 5th output)

from spec.

This issue refers to an old and obsolete version of RGB. See "old rgb" issue tag in our wiki.

from spec.