Timeline for OpenSSL Base64 output has wrong length
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 7, 2021 at 7:34 | history | edited | CommunityBot |
replaced https://tools.ietf.org/html/rfc with https://www.rfc-editor.org/rfc/rfc
|
|
| Mar 24, 2018 at 11:39 | history | edited | tehmoon | CC BY-SA 3.0 |
deleted 195 characters in body
|
| Mar 24, 2018 at 11:27 | comment | added | tehmoon | I see you point, so yes I think you are right. | |
| Mar 24, 2018 at 1:55 | comment | added | dave_thompson_085 | Yes, 04 is for uncompressed but that is part of the point encoding; see the references. Compressed would be 02 or 03 plus 32 bytes X, versus uncompressed 04 plus 64 bytes X and Y. But the 00 for bitstring padding is ASN.1 overhead not part of the point. | |
| Mar 23, 2018 at 14:50 | history | edited | tehmoon | CC BY-SA 3.0 |
added 557 characters in body
|
| Mar 23, 2018 at 14:31 | comment | added | tehmoon |
Actually I think it is +4 because the key should be 64 bytes -- 256 bits long. If I remember right, there is the type of the key append to the BITSTRING. I've just tested it and there are 0x00 0x04 in front of it every time. I've just glanced at the rfc. So it is 0x00 for padding and 0x04 for compressed or uncompressed. I'll make the changes.
|
|
| Mar 23, 2018 at 2:59 | comment | added | dave_thompson_085 | Should be 2+2+19+3. For BITSTRING (only, not other DER types, thus not decoded by the generic parser) the first 'content' octet is not actual content but instead a count of unused=padding bits -- here always zero because X9.62/SEC1 point format is integral octets. | |
| Mar 22, 2018 at 20:08 | vote | accept | wortwart | ||
| Mar 22, 2018 at 14:16 | history | answered | tehmoon | CC BY-SA 3.0 |