search

rgb-archive / spec

[OLD!] RGB Protocol specifications for Bitcoin-based digital assets
https://rgb-org.github.io/
147 stars 26 forks source link

Privacy issues #2

Closed fedsten closed 7 years ago

fedsten commented 7 years ago

The current structure of the Color_Def present multiple privacy problems, in particular:

  1. RGB Version: this byte will always be set at 0 until further versions are developed, and even at that time there will probably be a dominant version having most of the RGB transactions set with the same version number. Even if it is just a byte, it can help an attacker to identify RGB transactions.

  2. Second input position : we can expect many transactions to have a single colored input, making this byte often set to 0xff, making easier for an attacker to identify many RGB transactions. A possible solution could be to increase the quantity of values that invalidated the second colored input field (e.g. 16 instead of only one). This would obviously reduce the number of input supported, however it seems a good trade-off between privacy and usability since most bitcoin transactions have less than 240 inputs.

  3. Second input field: we can expect many transactions to have a single colored input, making the 12 bytes set at 0xffffffffffffffff a very good indicator for an attacker interested in identify RGB transactions. Since this field is already considered invalid if the position byte is set to 0xff, I would suggest to put a random value here. RGB client will ignore it anyway when they see the position byte set to 0xff, but the transaction will be far less identifiable.

  4. bytes 29-32: we can expect most of RGB transactions to have at least 3 outputs, but the colored ones could be even only one. In general, setting at 0xff the last bytes of all the transactions with few colored outputs is very bad for privacy. Assuming the transaction has n outputs and m colored outputs (m<n<6): m output fields will be correctly set to the actual colored output position n-m output fields will be set to any random value >n (hence invalid) 5-n fields will be set to any random number, as RGB clients will just ignore this field

inaltoasinistra commented 7 years ago

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

fedsten commented 7 years ago

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.

inaltoasinistra commented 7 years ago

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

RCasatta commented 7 years ago

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 https://github.com/BHBNETWORK/RGB/issues/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)

SimoneBronzini commented 7 years ago

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.

afilini commented 6 years ago

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