Lack of entropy for encryption keys about spec HOT 11 CLOSED

The derivation path is it only another way to brute force the key. The attacker will use the cheaper way, so we must take care about both.

It is actually way easier to bruteforce two 12-byte keys than to bruteforce six levels of non-hardened HD keys. In fact: deriving a HD node is more computationally expensive than generating the next possible key to bruteforce. Furthermore, bruteforcing the HD tree has the same computational complexity of bruteforcing both K and J (i.e. you don't know that you have found the right K until you also find the right J), while bruteforcing K alone reveals J per the protocol specs.

Otherwise we could use a one-way function to hide keys from addresses derivations.
For example
K' = hash(K)
Derivation path: xpub/K'1/K'2/K'3/K'4

Though this is a viable alternative, I dont't think this adds more security, assuming K and J are cryptographically-securely generated. Also, this would still need extra care, as in this case we'd need to split K in 8 chunks (assuming hash is a sha256 function) and still set the first bit to 0

from spec.

Currently the position of the two coloured inputs are expressed using two bytes, however if we make the protocol define that the coloured inputs always have to stay in first or second (when applicable) position,

This is not possible because positions of inputs depends by previous transactions, and they cannot be arbitrary chosen

from spec.

This is not possible because positions of inputs depends by previous transactions, and they cannot be arbitrary chosen

Well, I am not sure what you mean by this. In Bitcoin I can have an input (txid₁, n+1) in a position that appears before input (txid₂, n) (take this tx as an example). I don't see why one cannot do that in RGB transactions.

from spec.

I don't see why one cannot do that in RGB transactions.

Ops, I was wrong, I confused outputs of previous transaction with inputs.

I think that the motivation of specify input and output positions into Color_Def is guarantee privacy. If positions are fixed it is easy to follow the assets without decoding Color_Def

from spec.

Enforcing input and output order to save space is not recommended for the following reasons:

• By forcing positions you are leaking privacy
• You cannot mix colored transaction in join market transactions (which can grant you more privacy)
• It's possible that one day will be encouraged/enforced a deterministic ordering of outputs which leaks less privacy, for example you can't do forensics based on tx building rules of some wallet (I haven't a reference but it was proposed by some core dev)

however 96 bits are not considered enough for today's security standards

Many still consider 80 bits enough for symmetric keys ...
However I understand the worries and obviously I would like to have more entropy too. By using 6 bits to specify version and inputs/outputs position we can save 2 bytes and squeeze out 1 more entropy byte (reaching 104 bits). To be honest I consider this a much bigger problem...

Since we have versioning I would consider migrate to 80 bytes OP_RETURN an option for later upgrades.

If we consider to attack the derivation path instead of the encrypted Color_Def practically it takes about a day to iterate over one bip32 derivation. So it takes 2^64 days of a single computer to iterate over 96 bit. And this attack leaks privacy, do not steal bitcoins, so there aren't the same incentives.

from spec.

Many still consider 80 bits enough for symmetric keys ...

Since our data is public and stored into the blockchain we should be future proof.

The derivation path is it only another way to brute force the key. The attacker will use the cheaper way, so we must take care about both.
Otherwise we could use a one-way function to hide keys from addresses derivations.
For example
K' = hash(K)
Derivation path: xpub/K'1/K'2/K'3/K'4

from spec.

Since we have versioning I would consider migrate to 80 bytes OP_RETURN an option for later upgrades.

I believe that for improved fungibility it is better to have all the versions with the same number of bytes, making transaction clustering more difficult. At current rates, using 80 bytes instead of 32 will only cost 5000 extra satoshis

from spec.

I don't consider reasoning about today rates a good judgment parameter, just some months ago was 30 times more expensive...

However it's probably a safest path to increase the cost of the tx and have more entropy for the privacy...

from spec.

It is actually way easier to bruteforce two 12-byte keys than to bruteforce six levels of non-hardened HD keys.

This would change if a key derivation function is applied to the 12 bytes. Btw the one way function purpose is reduce the attack surface.

from spec.

This would change if a key derivation function is applied to the 12 bytes.

I am not sure what you mean by this.

Btw the one way function purpose is reduce the attack surface.

If the attack surface were the HD tree, a one-way function would help. But being the attack surface the key itself, a one-way function would not increase its entropy, apart from making the bruteforcing process a bit slower.

from spec.

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

from spec.