feat: constrain (r, s, v) signature values #259
Conversation
karmacoma-eth
commented
Mar 23, 2024
karmacoma-eth
commented
- BadElections in examples/simple
- test for EIP-2098 compact signatures
Sort of an integration test to make sure that the (v, r, s) values we generate can be encoded and decoded properly in ECDSA.tryRecover
(to their expected range)
+ document missing feature in our implementation of ecrecover
| """Extract bytes from calldata. Zero-pad if out of bounds.""" | ||
| if data is None: | ||
| return BitVecVal(0, size_bytes * 8) | ||
|
|
There was a problem hiding this comment.
could you add a regression test that would fail without this fix? (it's not clear when None can be passed to this function.) also, does this fix the vm.etch(x, "") case as well?
There was a problem hiding this comment.
it's related but separate from the vm.etch(x, "") issue, we don't have a very nice way to deal with empty bytes in general. They get sometimes represented as bytes(), sometimes as [], sometimes as None
the test that revealed this issue is check_ecrecover_invalidCallReturnsNothing, in the following line:
let succ := call(gas(), ECRECOVER_PRECOMPILE, 0, 0, 0, 0, 0)
There was a problem hiding this comment.
thanks. now i can see where None comes from. as you mentioned, i agree that we need a better way to handle nicely empty bytes. could you please open an issue about this to discuss further later?
|
replied to the question on the commit, but copying here just in case:
|
