miracl / core

MIRACL Core
Apache License 2.0
199 stars 68 forks source link

Javascript ecp2 toBytes functions gives not the same bytes as in the Java implementation #43

Closed CryptoMathician closed 3 years ago

CryptoMathician commented 3 years ago

Hi,

I have an ECP2 object in Java which is represented by the following string

([136bcbb1223d222a31d2f061371bfdb3c767eab89bc93891a05c20f553b0760c2338c488510403d0c79246325a11b4f1d7c7ba7d5ca511e45a0f,0aa14639fa52f98d0086b171ecd57308243d4576629bc251f470a4fba78b443516e78b3c3ebab0763eec0497f82e67aac35ff4920aef1c90ccb7],[076f7c78c7965f9a723eed6cd0e4961c612147ee0951967a3a444a8cb899dbbd48471e08578ae8b79526d37abaf4a75b40495be81233328346e6,141b1164820f78687ff9ed73b3667955ff3a81b7951774a559295d72dd62a0ea8c3c626f100fec2c2a2010c8d459b293d5c0c2dbf3565d19f099])

Another ECP2 Object in JavaScript is represented by the same string. From my understanding now it should be the same object, also the internal structure is maybe a bit different?! However, I get not the same byte array out of the object when I use the toBytes method. I get the following byte arrays:

[19, 107, -53, -79, 34, 61, 34, 42, 49, -46, -16, 97, 55, 27, -3, -77, -57, 103, -22, -72, -101, -55, 56, -111, -96, 92, 32, -11, 83, -80, 118, 12, 35, 56, -60, -120, 81, 4, 3, -48, -57, -110, 70, 50, 90, 17, -76, -15, -41, -57, -70, 125, 92, -91, 17, -28, 90, 15, 10, -95, 70, 57, -6, 82, -7, -115, 0, -122, -79, 113, -20, -43, 115, 8, 36, 61, 69, 118, 98, -101, -62, 81, -12, 112, -92, -5, -89, -117, 68, 53, 22, -25, -117, 60, 62, -70, -80, 118, 62, -20, 4, -105, -8, 46, 103, -86, -61, 95, -12, -110, 10, -17, 28, -112, -52, -73, 7, 111, 124, 120, -57, -106, 95, -102, 114, 62, -19, 108, -48, -28, -106, 28, 97, 33, 71, -18, 9, 81, -106, 122, 58, 68, 74, -116, -72, -103, -37, -67, 72, 71, 30, 8, 87, -118, -24, -73, -107, 38, -45, 122, -70, -12, -89, 91, 64, 73, 91, -24, 18, 51, 50, -125, 70, -26, 20, 27, 17, 100, -126, 15, 120, 104, 127, -7, -19, 115, -77, 102, 121, 85, -1, 58, -127, -73, -107, 23, 116, -91, 89, 41, 93, 114, -35, 98, -96, -22, -116, 60, 98, 111, 16, 15, -20, 44, 42, 32, 16, -56, -44, 89, -78, -109, -43, -64, -62, -37, -13, 86, 93, 25, -16, -103, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

and as an Array in JavaScript

[4,10,161,70,57,250,82,249,141,0,134,177,113,236,213,115,8,36,61,69,118,98,155,194,81,244,112,164,251,167,139,68,53,22,231,139,60,62,186,176,118,62,236,4,151,248,46,103,170,195,95,244,146,10,239,28,144,204,183,19,107,203,177,34,61,34,42,49,210,240,97,55,27,253,179,199,103,234,184,155,201,56,145,160,92,32,245,83,176,118,12,35,56,196,136,81,4,3,208,199,...]

As an Int8Array I get:

{
  "0": 4,
  "1": 10,
  "2": -95,
  "3": 70,
  "4": 57,
  "5": -6,
  "6": 82,
  "7": -7,
  "8": -115,
  "9": 0,
  "10": -122,
  "11": -79,
  "12": 113,
  "13": -20,
  "14": -43,
  "15": 115,
  "16": 8,
  "17": 36,
  "18": 61,
  "19": 69,
  "20": 118,
  ...
}

This seems to me a bit weird if I assume that both objects are the "same" in the sense that both objects represents the same ECP2 object x. I tried the following code in JavaScript:

let rawBytes = new Array(12*ctx.BIG.MODBYTES);
x.toBytes(rawBytes)

In Java the same code is:

byte[] rawBytes = new byte[CONFIG_BIG.MODBYTES*12];
x.toBytes(rawBytes);

with x is of type ECP2. Is there a chance that these objects are not the same or is there any bug in the toBytes() function in JavaScript? Or maybe I missed something else?

Thank you in advance!

CryptoMathician commented 3 years ago

Maybe as an additional comment. My goal was to produce a base64 string from the ECP2 object.

mcarrickscott commented 3 years ago

Not entirely sure what the point is here.

The first array is an ECP2 instance, in its internal format, in hex. The second is the same data "flattened" into a single array of signed bytes in decimal. Which is what tobytes() should do. It should however be of size 4ctx.BIG.MODBYTES, not 12 - maybe that is the problem??

I couldn't relate the other arrays to these ones..

Mike

On Sun, Apr 18, 2021 at 10:32 PM Pascal Schäfer @.***> wrote:

Hi,

I have an ECP2 object in Java which is represented by the following string

([136bcbb1223d222a31d2f061371bfdb3c767eab89bc93891a05c20f553b0760c2338c488510403d0c79246325a11b4f1d7c7ba7d5ca511e45a0f,0aa14639fa52f98d0086b171ecd57308243d4576629bc251f470a4fba78b443516e78b3c3ebab0763eec0497f82e67aac35ff4920aef1c90ccb7],[076f7c78c7965f9a723eed6cd0e4961c612147ee0951967a3a444a8cb899dbbd48471e08578ae8b79526d37abaf4a75b40495be81233328346e6,141b1164820f78687ff9ed73b3667955ff3a81b7951774a559295d72dd62a0ea8c3c626f100fec2c2a2010c8d459b293d5c0c2dbf3565d19f099])

Another ECP2 Object in JavaScript is represented by the same string. From my understanding now it should be the same object, also the internal structure is maybe a bit different?! However, I get not the same byte array out of the object when I use the toBytes method. I get the following byte arrays:

[19, 107, -53, -79, 34, 61, 34, 42, 49, -46, -16, 97, 55, 27, -3, -77, -57, 103, -22, -72, -101, -55, 56, -111, -96, 92, 32, -11, 83, -80, 118, 12, 35, 56, -60, -120, 81, 4, 3, -48, -57, -110, 70, 50, 90, 17, -76, -15, -41, -57, -70, 125, 92, -91, 17, -28, 90, 15, 10, -95, 70, 57, -6, 82, -7, -115, 0, -122, -79, 113, -20, -43, 115, 8, 36, 61, 69, 118, 98, -101, -62, 81, -12, 112, -92, -5, -89, -117, 68, 53, 22, -25, -117, 60, 62, -70, -80, 118, 62, -20, 4, -105, -8, 46, 103, -86, -61, 95, -12, -110, 10, -17, 28, -112, -52, -73, 7, 111, 124, 120, -57, -106, 95, -102, 114, 62, -19, 108, -48, -28, -106, 28, 97, 33, 71, -18, 9, 81, -106, 122, 58, 68, 74, -116, -72, -103, -37, -67, 72, 71, 30, 8, 87, -118, -24, -73, -107, 38, -45, 122, -70, -12, -89, 91, 64, 73, 91, -24, 18, 51, 50, -125, 70, -26, 20, 27, 17, 100, -126, 15, 120, 104, 127, -7, -19, 115, -77, 102, 121, 85, -1, 58, -127, -73, -107, 23, 116, -91, 89, 41, 93, 114, -35, 98, -96, -22, -116, 60, 98, 111, 16, 15, -20, 44, 42, 32, 16, -56, -44, 89, -78, -109, -43, -64, -62, -37, -13, 86, 93, 25, -16, -103, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

and as an Array in JavaScript

[4,10,161,70,57,250,82,249,141,0,134,177,113,236,213,115,8,36,61,69,118,98,155,194,81,244,112,164,251,167,139,68,53,22,231,139,60,62,186,176,118,62,236,4,151,248,46,103,170,195,95,244,146,10,239,28,144,204,183,19,107,203,177,34,61,34,42,49,210,240,97,55,27,253,179,199,103,234,184,155,201,56,145,160,92,32,245,83,176,118,12,35,56,196,136,81,4,3,208,199,...]

As an Int8Array I get:

{ "0": 4, "1": 10, "2": -95, "3": 70, "4": 57, "5": -6, "6": 82, "7": -7, "8": -115, "9": 0, "10": -122, "11": -79, "12": 113, "13": -20, "14": -43, "15": 115, "16": 8, "17": 36, "18": 61, "19": 69, "20": 118, ...}

This seems to me a bit weird if I assume that both objects are the "same" in the sense that both objects represents the same ECP2 object x. I tried the following code in JavaScript:

let rawBytes = new Array(12*ctx.BIG.MODBYTES);x.toBytes(rawBytes)

In Java the same code is:

byte[] rawBytes = new byte[CONFIG_BIG.MODBYTES*12]; x.toBytes(rawBytes);

with x is of type ECP2. Is there a chance that these objects are not the same or is there any bug in the toBytes() function in JavaScript? Or maybe I missed something else?

Thank you in advance!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/miracl/core/issues/43, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU3ZDQFJ3NJ7B46KVUDPE3TJNFX3ANCNFSM43EUP3HA .

CryptoMathician commented 3 years ago

Hi Mike,

exactly. The internal format in hex is in both implementation the same and that is why I assume that both ECP2 objects are the same (or is it possible that the objects are not the same with the same internal hex representation?). Unfortunately, the JavaScript implementation (second array of decimals) of ECP2 gives me not the same byte array as the Java implementation it does (first array of decimals) when I call toBytes(). Do I miss something? I think it is not because of the 12*ctx.BIG.MODBYTES or maybe I didn't get the point.

From my point of view of my understanding the ECP2 implementation in JavaScript should give me the same result when I call toBytes() or is the internal hex representation not enough to check if both objects are the same?

My question is, could you help me to figure out the problem why I not getting the same byte array in both implementations? I am not sure if I missed something or if it exist a bug in the implementation (or similar). I tried also if this is my fault because of the type of the array, but I don't get the correct bytes (decimals) when I use Uint8Array, Array or Int8Array. My goal was to produce a base64 string from the byte array which is representing ("flattened") the ECP2 object in signed/unsigned decimals.

Not entirely sure what the point is here. The first array is an ECP2 instance, in its internal format, in hex. The second is the same data "flattened" into a single array of signed bytes in decimal. Which is what tobytes() should do. It should however be of size 4ctx.BIG.MODBYTES, not 12 - maybe that is the problem?? I couldn't relate the other arrays to these ones.. Mike

mcarrickscott commented 3 years ago

Again, still not sure I am understanding the problem. Both arrays contain the same data - it is just a question of how to output them, in Hex or in Decimal. If you output the second array in Hex, it will look very like the first - see

https://stackoverflow.com/questions/34309988/byte-array-to-hex-string-conversion-in-javascript

The reason for all of the zeros at the end of the second array is that the array size is too large - 12ctx.BIG.MODBYTES instead of 4ctx.BIG.MODBYTES

Mike

On Mon, Apr 19, 2021 at 3:15 PM Pascal Schäfer @.***> wrote:

Hi Mike,

exactly. The internal format in hex is in both implementation the same and that is why I assume that both ECP2 objects are the same (or is it possible that the objects are not the same with the same internal hex representation?). Unfortunately, the JavaScript implementation (second array of decimals) of ECP2 gives me not the same byte array as the Java implementation it does (first array of decimals) when I call toBytes(). Do I miss something? I think it is not because of the 12*ctx.BIG.MODBYTES or maybe I didn't get the point.

From my point of view of my understanding the ECP2 implementation in JavaScript should give me the same result when I call toBytes() or is the internal hex representation not enough to check if both objects are the same?

My question is, could you help me to figure out the problem why I not getting the same byte array in both implementations? I am not sure if I missed something or if it exist a bug in the implementation (or similar). I tried also if this is my fault because of the type of the array, but I don't get the correct bytes (decimals) when I use Uint8Array, Array or Int8Array. My goal was to produce a base64 string from the byte array which is representing ("flattened") the ECP2 object in signed/unsigned decimals.

Not entirely sure what the point is here. The first array is an ECP2 instance, in its internal format, in hex. The second is the same data "flattened" into a single array of signed bytes in decimal. Which is what tobytes() should do. It should however be of size 4ctx.BIG.MODBYTES, not 12 - maybe that is the problem?? I couldn't relate the other arrays to these ones.. Mike … <#m-6990611802545923966>

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/miracl/core/issues/43#issuecomment-822501145, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAU3ZDTNNIGPJ4ASDSR3NU3TJQ3JFANCNFSM43EUP3HA .

CryptoMathician commented 3 years ago

I found the issue. I did a mistake.