-
Notifications
You must be signed in to change notification settings - Fork 172
der: support for the REAL type #346
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
der: support for the REAL type #346
Conversation
Source: https://www.oss.com/asn1/resources/books-whitepapers-pubs/larmouth-asn1-book.pdf, page 174 Signed-off-by: Christopher Rabotin <[email protected]>
Signed-off-by: Christopher Rabotin <[email protected]>
Signed-off-by: Christopher Rabotin <[email protected]>
Signed-off-by: Christopher Rabotin <[email protected]>
Signed-off-by: Christopher Rabotin <[email protected]>
Signed-off-by: Christopher Rabotin <[email protected]>
Covers sections 8.5 and 11.3 of ITU-T X.690 (02/2021) Caveats: 1. Interpretation of section 11.3.1 to be further discussed 2. Currently, all encoding is binary (no ISO 6093 NR3) Testing of arbitrarily large and small f64s shows that DER typically requires 12 bytes to encode these 8-byte IEEE-754 values. This can be explained because of the extra two bytes for the tag and length, and the fact that the exponent is encoded on 1 to 2 bytes (only 11 bits in IEEE-754), and the mantissa may require up to 8 bytes itself, hence 12 bytes total. Of note that, depending on Caveat 1 above, this information may be wrong.
…otin/formats into 304-der-support-real-type
Signed-off-by: Christopher Rabotin <[email protected]>
Signed-off-by: Christopher Rabotin <[email protected]>
|
If you can find another implementation to do interop testing with, that'd be great |
Co-authored-by: Tony Arcieri <[email protected]>
Co-authored-by: Tony Arcieri <[email protected]>
|
Thanks for the review. I'll add a demo encoding from the ASN1 playground |
Signed-off-by: Christopher Rabotin <[email protected]>
|
As a quick update, I'm working on adding a bunch of validation test cases. It's gonna take some time as it seems like some of my encoding does not match the ASN1 playground so I'm going through the specs again to better understand what I didn't implement correctly. I'll keep the branch up-to-date with master. |
Signed-off-by: Christopher Rabotin <[email protected]>
…otin/formats into 304-der-support-real-type
Signed-off-by: Christopher Rabotin <[email protected]>
Signed-off-by: Christopher Rabotin <[email protected]>
These were commented because the ASN1 playground encodes in NR3 (base 10) but this impl only encodes in base 2, so the reciprocity tests would never have worked. Instead, all other cases were tested for decoding in the ASN1 playground. Signed-off-by: Christopher Rabotin <[email protected]>
|
After a two months of working on other stuff, here's the updated PR with validation cases. Let me know if you have any questions. I'm not sure why clippy is failing in the Github actions, it works locally with Cheers |
Signed-off-by: Christopher Rabotin <[email protected]>
Signed-off-by: Christopher Rabotin <[email protected]>
|
Not sure what this CI build failed as running |
|
It's failing here: https://github.com/RustCrypto/formats/runs/5669154521?check_suite_focus=true I think the issue is that this is using the new captured identifiers in format strings feature which was introduced in Rust 1.58, and the MSRV of the crate is 1.57, which is what the test is failing on. |
Signed-off-by: Christopher Rabotin <[email protected]>
|
Fixed, thanks! |
Co-authored-by: Tony Arcieri <[email protected]>
|
Thanks for the suggestion, that fixed all of the tests. |
Signed-off-by: Christopher Rabotin <[email protected]>
|
Thank you! |
Covers sections 8.5 and 11.3 of ITU-T X.690 (02/2021)
Caveats:
1. Interpretation of section 11.3.1 to be further discussed
2. Currently, all encoding is binary (no ISO 6093 NR3)
Testing of arbitrarily large and small f64s shows that DER typically
requires 12 bytes to encode these 8-byte IEEE-754 values. This can be
explained because of the extra two bytes for the tag and length, and the
fact that the exponent is encoded on 1 to 2 bytes (only 11 bits in
IEEE-754), and the mantissa may require up to 8 bytes itself, hence 12
bytes total. Of note that, depending on Caveat 1 above, this information
may be wrong.
Closes #304