Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

IS test data parsing

See original GitHub issue

There seems to be an issue with parsing IS test data 1.json, Specifically, after CBOR decoding, I find that the CBOR payload and signature are interpreted as BigInt instead of byte arrays:

PAYLOAD is:
2397332141485256913488704505433799668901681210996589429024717003411457267267737103471192134824685872060131956781282948858694305243148748015395210653060449176636752127703256346789592234255080197478223890418992522464684436809778487593006808754117912994432346426218750419887858217878871418332034023975018415296636335405856653237289595829881796373198766114484874751162399213807395457310978928060601624487963305305563921791118735667840058106294036589126108034317784154871354534094734700074876481112826646170361932454775140726608423911296697168873547533348654263331717397936300817799855119773320095486902679300101478204301407474120147646365063877627679255692098128578134251946811223897149623032098352

instead of expected:
[0, 164, 1, 98, 73, 83, 4, 26, 96, 159, 194, 77, 6, 26, 96, 150, 135, 205, 57, 1, 3, 161, 1, 164, 97, 118, 129, 170, 98, 99, 105, 111, 48, 49, 32, 73, 83, 47, 65, 66, 67, 49, 50, 51, 52, 35, 75, 98, 99, 111, 98, 73, 83, 98, 100, 110, 2, 98, 100, 116, 120, 25, 50, 48, 50, 49, 45, 48, 49, 45, 48, 49, 84, 48, 48, 58, 48, 48, 58, 48, 48, 43, 48, 48, 58, 48, 48, 98, 105, 115, 120, 37, 68, 105, 114, 101, 99, 116, 111, 114, 97, 116, 101, 32, 111, 102, 32, 72, 101, 97, 108, 116, 104, 32, 111, 102, 32, 73, 99, 101, 108, 97, 110, 100, 32, 84, 101, 115, 116, 98, 109, 97, 109, 79, 82, 71, 45, 49, 48, 48, 48, 51, 48, 50, 49, 53, 98, 109, 112, 108, 69, 85, 47, 49, 47, 50, 48, 47, 49, 53, 50, 56, 98, 115, 100, 2, 98, 116, 103, 105, 56, 52, 48, 53, 51, 57, 48, 48, 54, 98, 118, 112, 103, 74, 48, 55, 66, 88, 48, 51, 99, 100, 111, 98, 106, 50, 48, 48, 48, 45, 48, 49, 45, 48, 49, 99, 110, 97, 109, 164, 98, 102, 110, 107, 80, 114, 195, 179, 102, 97, 114, 97, 115, 111, 110, 98, 103, 110, 112, 195, 158, 97, 114, 102, 32, 65, 195, 176, 32, 80, 114, 195, 179, 102, 97, 99, 102, 110, 116, 106, 80, 82, 79, 70, 65, 82, 65, 83, 79, 78, 99, 103, 110, 116, 110, 84, 72, 65, 82, 70, 60, 65, 68, 60, 80, 82, 79, 70, 65, 99, 118, 101, 114, 101, 49, 46, 48, 46, 48]

SIGNATURE is:
10715071909929086383423430506437304501550241673948456133261033394280262656208439362876801109707780458851648136614858804193380332620123554389411733878497153

instead of expected:
[0, 204, 150, 46, 53, 134, 197, 145, 201, 149, 55, 234, 33, 22, 75, 203, 200, 156, 52, 109, 255, 236, 200, 182, 70, 68, 82, 231, 201, 94, 56, 77, 134, 12, 174, 134, 141, 164, 186, 219, 6, 87, 102, 141, 21, 150, 129, 95, 254, 27, 166, 113, 52, 30, 207, 170, 123, 87, 144, 14, 194, 166, 122, 95, 129]

While I am able to convert the values back to byte arrays and extract the data, the signature verification fails. I am suspecting this is caused due to incorrect originally signed data. My calculated data-to-be-signed payload is:

[132, 106, 83, 105, 103, 110, 97, 116, 117, 114, 101, 49, 78, 162, 1, 38, 4, 196, 72, 53, 38, 235, 161, 22, 74, 29, 84, 64, 89, 1, 33, 0, 164, 1, 98, 73, 83, 4, 26, 96, 159, 194, 77, 6, 26, 96, 150, 135, 205, 57, 1, 3, 161, 1, 164, 97, 118, 129, 170, 98, 99, 105, 111, 48, 49, 32, 73, 83, 47, 65, 66, 67, 49, 50, 51, 52, 35, 75, 98, 99, 111, 98, 73, 83, 98, 100, 110, 2, 98, 100, 116, 120, 25, 50, 48, 50, 49, 45, 48, 49, 45, 48, 49, 84, 48, 48, 58, 48, 48, 58, 48, 48, 43, 48, 48, 58, 48, 48, 98, 105, 115, 120, 37, 68, 105, 114, 101, 99, 116, 111, 114, 97, 116, 101, 32, 111, 102, 32, 72, 101, 97, 108, 116, 104, 32, 111, 102, 32, 73, 99, 101, 108, 97, 110, 100, 32, 84, 101, 115, 116, 98, 109, 97, 109, 79, 82, 71, 45, 49, 48, 48, 48, 51, 48, 50, 49, 53, 98, 109, 112, 108, 69, 85, 47, 49, 47, 50, 48, 47, 49, 53, 50, 56, 98, 115, 100, 2, 98, 116, 103, 105, 56, 52, 48, 53, 51, 57, 48, 48, 54, 98, 118, 112, 103, 74, 48, 55, 66, 88, 48, 51, 99, 100, 111, 98, 106, 50, 48, 48, 48, 45, 48, 49, 45, 48, 49, 99, 110, 97, 109, 164, 98, 102, 110, 107, 80, 114, 195, 179, 102, 97, 114, 97, 115, 111, 110, 98, 103, 110, 112, 195, 158, 97, 114, 102, 32, 65, 195, 176, 32, 80, 114, 195, 179, 102, 97, 99, 102, 110, 116, 106, 80, 82, 79, 70, 65, 82, 65, 83, 79, 78, 99, 103, 110, 116, 110, 84, 72, 65, 82, 70, 60, 65, 68, 60, 80, 82, 79, 70, 65, 99, 118, 101, 114, 101, 49, 46, 48, 46, 48]

@gunnarif can you please confirm what the originally signed payload is and what causes this discrepancy?

Issue Analytics

State:
Created 2 years ago
Comments:7 (4 by maintainers)

Top GitHub Comments

1reaction

JChristcommented, May 11, 2021

hi @gunnarif I’ve tried using the test data in 1.json inside your PR and I can confirm that the above-mentioned issue is resolved in them!

0reactions

daniel-edercommented, May 12, 2021

Thanks for fixing & verifying!

Top Results From Across the Web

Testing a DFDL schema by parsing test input data - IBM

Click Test parse model, or right-click the message that you want to test and click Test parse model. The Test Parse Model window...

What is data parsing? - ScrapingBee

Data parsing is the process of taking data in one format and transforming it to another format. You'll find parsers used everywhere.

What Is Parsing of Data? - Oxylabs

Data parsing is a method where one string of data gets converted into a different type of data. So let's say you receive...

How to Unit-Test a parser of a file?

I'm refactoring a parser and want to test the 'parse()' method. ... Your tests will have the data to test your parser.

Better way to test (automatically) a parser? - Stack Overflow

The definition of parsing correctly is accepting strings that belong to the language and rejecting the ones that don't. There are languages that ......