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
Using leInt2Buff returns inaccurate results depending on the length of the input. I discovered this when constructing a buffer from a small value, eg BigInt(42). When using leInt2Buff(BigInt(42)), the result is Uint8Array(1) [1], whereas the expected result is Uint8Array(1) [42].
My solution in this case is to strictly specify the length passed into leInt2Buff (and to make sure its a multiple of 4). That being said, this issue might go undetected by a consumer of this library, and that could potentially impact the security of a zero knowledge application.
For example, if someone were to write a zk app that uses the pedersenHash of a value that is less than 4 bytes long (up to 2^32). If the primage depends on a Buffer constructed from this function there will be unintentional collisions, because for example leInt2Buff(BigInt(42)) == leInt2Buff(BigInt(216)) == Uint8Array(1) [1] (and there are more repeated patterns up until you exceed 4 bytes, then the pattern changes again).
Steps to Reproduce
Run this script.
const{ leInt2Buff }=require('ffjavascript').utils;constnum=BigInt(42);console.log('num: ',num);console.log('leInt2Buff len = undefined: ',leInt2Buff(num));for(leti=1;i<33;i++){console.log(`leInt2Buff len = ${i}: `,leInt2Buff(num,i));}
The pattern of ones at the end of the array continues so on and so forth up until len = 32.
Here's another script, this time comparing 216 vs 42:
constnum1=BigInt(216);console.log('num1: ',num1);console.log('leInt2Buff len = undefined: ',leInt2Buff(num1));console.log('leInt2Buff len = 32: ',leInt2Buff(num1,32));constnum2=BigInt(42);console.log('num2: ',num2);console.log('leInt2Buff len = undefined: ',leInt2Buff(num2));console.log('leInt2Buff len = 32: ',leInt2Buff(num2,32));
Description of the Problem
Using
leInt2Buff
returns inaccurate results depending on the length of the input. I discovered this when constructing a buffer from a small value, egBigInt(42)
. When usingleInt2Buff(BigInt(42))
, the result isUint8Array(1) [1]
, whereas the expected result isUint8Array(1) [42]
.My solution in this case is to strictly specify the length passed into
leInt2Buff
(and to make sure its a multiple of 4). That being said, this issue might go undetected by a consumer of this library, and that could potentially impact the security of a zero knowledge application.For example, if someone were to write a zk app that uses the pedersenHash of a value that is less than 4 bytes long (up to 2^32). If the primage depends on a Buffer constructed from this function there will be unintentional collisions, because for example
leInt2Buff(BigInt(42)) == leInt2Buff(BigInt(216)) == Uint8Array(1) [1]
(and there are more repeated patterns up until you exceed 4 bytes, then the pattern changes again).Steps to Reproduce
Run this script.
The truncated results of the above script:
The pattern of ones at the end of the array continues so on and so forth up until len = 32.
Here's another script, this time comparing 216 vs 42:
I ran this script in a local project with the following package.json:
The text was updated successfully, but these errors were encountered: