pallet_revive: Change address derivation to use hashing (#7662)
Fixes https://github.com/paritytech/polkadot-sdk/issues/6723
## Motivation
Internal auditors recommended to not truncate Polkadot Addresses when
deriving Ethereum addresses from it. Reasoning is that they are raw
public keys where truncating could lead to collisions when weaknesses in
those curves are discovered in the future. Additionally, some pallets
generate account addresses in a way where only the suffix we were
truncating contains any entropy. The changes in this PR act as a safe
guard against those two points.
## Changes made
We change the `to_address` function to first hash the AccountId32 and
then use trailing 20 bytes as `AccountId20`. If the `AccountId32` ends
with 12x 0xEE we keep our current behaviour of just truncating those
trailing bytes.
## Security Discussion
This will allow us to still recover the original `AccountId20` because
those are constructed by just adding those 12 bytes. Please note that
generating an ed25519 key pair where the trailing 12 bytes are 0xEE is
theoretically possible as 96bits is not a huge search space. However,
this cannot be used as an attack vector. It will merely allow this
address to interact with `pallet_revive` without registering as the
fallback account is the same as the actual address. The ultimate vanity
address. In practice, this is not relevant since the 0xEE addresses are
not valid public keys for sr25519 which is used almost everywhere.
tl:dr: We keep truncating in case of an Ethereum address derived account
id. This is safe as those are already derived via keccak. In every other
case where we have to assume that the account id might be a public key.
Therefore we first hash and then take the trailing bytes.
## Do we need a Migration for Westend
No. We changed the name of the mapping. This means the runtime will not
try to read the old data. Ethereum keys are unaffected by this change.
We just advise people to re-register their AccountId32 in case they need
to use it as it is a very small circle of users (just 3 addresses
registered). This will not cause disturbance on Westend.
---------
Co-authored-by:
cmd[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Showing
- Cargo.lock 0 additions, 1 deletionCargo.lock
- prdoc/pr_7662.prdoc 26 additions, 0 deletionsprdoc/pr_7662.prdoc
- substrate/frame/revive/Cargo.toml 0 additions, 2 deletionssubstrate/frame/revive/Cargo.toml
- substrate/frame/revive/fixtures/contracts/terminate_and_send_to_argument.rs 3 additions, 3 deletions...vive/fixtures/contracts/terminate_and_send_to_argument.rs
- substrate/frame/revive/src/address.rs 42 additions, 30 deletionssubstrate/frame/revive/src/address.rs
- substrate/frame/revive/src/evm/api/byte.rs 2 additions, 0 deletionssubstrate/frame/revive/src/evm/api/byte.rs
- substrate/frame/revive/src/evm/api/hex_serde.rs 1 addition, 0 deletionssubstrate/frame/revive/src/evm/api/hex_serde.rs
- substrate/frame/revive/src/evm/api/rlp_codec.rs 1 addition, 1 deletionsubstrate/frame/revive/src/evm/api/rlp_codec.rs
- substrate/frame/revive/src/evm/api/signature.rs 2 additions, 1 deletionsubstrate/frame/revive/src/evm/api/signature.rs
- substrate/frame/revive/src/lib.rs 6 additions, 5 deletionssubstrate/frame/revive/src/lib.rs
- substrate/frame/revive/src/test_utils.rs 25 additions, 8 deletionssubstrate/frame/revive/src/test_utils.rs
- substrate/frame/revive/src/tests.rs 34 additions, 3 deletionssubstrate/frame/revive/src/tests.rs
Please register or sign in to comment