Expanded malleability risks.

This commit is contained in:
chriseth 2016-07-06 18:33:38 +02:00 committed by GitHub
parent 2edbd0605c
commit b71144dd53

View File

@ -146,7 +146,11 @@ Minor Details
Furthermore, it is not enforced by the EVM, so a contract function that "claims" Furthermore, it is not enforced by the EVM, so a contract function that "claims"
to be constant might still cause changes to the state. to be constant might still cause changes to the state.
- Types that do not occupy the full 32 bytes might contain "dirty higher order bits". - Types that do not occupy the full 32 bytes might contain "dirty higher order bits".
This is especially important if you access ``msg.data`` - it poses a malleability risk. This is especially important if you access ``msg.data`` - it poses a malleability risk:
You can craft transactions that call a function ``f(uint8 x)`` with a raw byte argument
of ``0xff000001`` and with ``0x00000001``. Both are fed to the contract and both will
look like the number ``1`` as far as ``x`` is concerned, but ``msg.data`` will
be different, so if you use ``sha3(msg.data)`` for anything, you will get different results.
*************** ***************
Recommendations Recommendations
@ -218,4 +222,4 @@ it will be better documented soon.
Note that formal verification itself can only help you understand the Note that formal verification itself can only help you understand the
difference between what you did (the specification) and how you did it difference between what you did (the specification) and how you did it
(the actual implementation). You still need to check whether the specification (the actual implementation). You still need to check whether the specification
is what you wanted and that you did not miss any unintended effects of it. is what you wanted and that you did not miss any unintended effects of it.