fix(precompile): use big-endian resize for modexp output padding#3432
fix(precompile): use big-endian resize for modexp output padding#3432rakita merged 3 commits intobluealloy:mainfrom
Conversation
Merging this PR will improve performance by 3.62%
Performance Changes
Comparing 
|
rakita
left a comment
There was a problem hiding this comment.
I see, this only can happen if crypto().modexp returns some badly formated data.
for style lets create left_pad_vec_be that would do a similar thing to left_pad_vec
Address review feedback to match the existing left_pad_vec naming convention. Also change the API to take &[u8] and return Cow<[u8]> instead of mutating a Vec in place.
|
@Wollac can you check if changes are okay. And will merge afterwards |
|
Yes, this fixes the issue I observed. |
|
@Wollac i see, will check this in saparate PR. Will merge this as we will be releasing new version soon(tm) |
Summary
left_pad_vecwith a newresize_beutility for modexp output normalization.left_pad_vecincorrectly truncates trailing (least-significant) bytes when the output exceedsmod_len. This is incorrect for big-endian values.resize_beutility correctly handles both padding (left-pad with zeroes) and truncation (drop leading bytes).Motivation
crypto().modexp()is a trait method that can be overridden, so the output may exceedmod_lenbytes and contain leading zeroes. The previous code silently corrupted results in that case by truncating from the wrong side.resize_beonly assumes the mathematical invariant that the output value is< modulus, not any specific byte length.