Fix finding 11 : use length for rlc in rlp table

[kunxian-xia]

Description

This pr add two more columns in the RLP table to fix the finding 11 in the Zellic / Kalos Audit Report.

1. be_bytes_rlc
2. be_bytes_length

Then we also need to change the lookup arguments (into RLP table) in tx circuit.

Issue Link

The tx's fields are decoded from tx hash and then encoded into tx sign. Previously, we use field's accumulated value to copy big-endian bytes around. But this has one critical vulnerability in which field of type u64 can have different big-endian bytes whose value is same.

For example, 1_u64 = [1] = [0, 1] = [0, 0, 1] = ... . This will cause the msg_hash can be manipulated by an malicious prover. To fix that, we can add RLC(be_bytes) in the RLP table in addition to the old tag_value_acc = LC(be_bytes).

However, this alone still has another vulnerability. We can have append arbitrary number of zeros in the end of be_bytes and still have same RLC. To fix this, we add length(be_bytes) in the RLP table too.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

[roynalnaruto]

Just wanted you to double check on the byte size of those fields.

Suggestion for cleaner code:
How about you define a trait ByteSize that has a byte_size method and implement it for fields such as u64, U256 and others that we require to find the byte_size of and assign to tag_length ?

So then you can simply call the byte_size method instead of doing 256 - leading_zeros/8 and so on...

Its a nit-pick but might help.

[lispc]

mix usage of 0 and Value::unknown can be dangerous sometimes. I did not check carefully. But we may need double check for codes like map_or(Value::known(F::zero())....