You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use BigInt mostly in modular arithmetic where there's no negative numbers. However, negative BigInt can be mistakenly constructed and cause a wrong behaviour.
One way to work around this problem would be replacing BigInt with BigUint that has no sign. Achieving negative number (e.g. BigUint::zero() - BigUint::one()) would cause a panic. But this is not a reliable solution for cryptographic library.
Better option would be allowing BigInt to participate only in modular arithmetic operations. I.e. arithmetic expression should not be evaluated unless module value is specified. This reminds me a lazy evaluation from functional world. I've wrote a simple PoC: here.
The text was updated successfully, but these errors were encountered:
We use BigInt mostly in modular arithmetic where there's no negative numbers. However, negative BigInt can be mistakenly constructed and cause a wrong behaviour.
One way to work around this problem would be replacing BigInt with BigUint that has no sign. Achieving negative number (e.g.
BigUint::zero() - BigUint::one()
) would cause a panic. But this is not a reliable solution for cryptographic library.Better option would be allowing BigInt to participate only in modular arithmetic operations. I.e. arithmetic expression should not be evaluated unless module value is specified. This reminds me a lazy evaluation from functional world. I've wrote a simple PoC: here.
The text was updated successfully, but these errors were encountered: