2 ms·

Maybe it's just because I've never needed the complexity, but ASN.1 seems a bit much for any of the formats I've created.

zzo38computer 1y ago
For me too, although you only need to use (and implement) the parts which are relevant for your application and not all of them, so it is not really the problem. (I also never needed to write ASN.1 schemas, and a full implementation of ASN.1 is not necessary for my purpose.) (This is also a reason I use DER instead of BER, even if canonical form is not required; DER is simpler to handle than all of the possibilities of BER.)
jeroenhd 1y ago
The ASN.1 format itself is pretty well-suited for generic file types. Unfortunately, there are very few good, open source/free ASN.1 (de)serializers out there. In theory you could use ASN.1 DER files the same way you would JSON for human-readable formats. In practice, you're better off picking a different format. Modern evolutions of ASN.1 like ProtoBuf or Cap'n Proto designed for transmitting data across the network might fit this purpose pretty well, too. On the other hand, using ASN.1 may be a good way to make people trying to reverse engineer your format give up in despair, especially if you start using the quirks ASN.1 DER comes with and change the identifiers.
- zzo38computer 1y ago
  > Unfortunately, there are very few good, open source/free ASN.1 (de)serializers out there. I wrote a library to read/write DER, which I have found suitable for my uses. (Although, I might change or add some things later, and possibly also some things might be removed too if I think they are unnecessary or cause problems.) https://github.com/zzo38/scorpion/blob/trunk/asn1/asn1.c https://github.com/zzo38/scorpion/blob/trunk/asn1/asn1.c https://github.com/zzo38/scorpion/blob/trunk/asn1/asn1.h https://github.com/zzo38/scorpion/blob/trunk/asn1/asn1.h (You can complain about it if there is something that you don't like.) > In theory you could use ASN.1 DER files the same way you would JSON for human-readable formats. In practice, you're better off picking a different format. I do use ASN.1 DER for some things, because, in my opinion it is (generally) better than JSON, XML, etc. > Modern evolutions of ASN.1 like ProtoBuf or Cap'n Proto designed for transmitting data across the network might fit this purpose pretty well, too. I have found them to be unsuitable, with many problems, and that ASN.1 does them better in my experience. > On the other hand, using ASN.1 may be a good way to make people trying to reverse engineer your format give up in despair, especially if you start using the quirks ASN.1 DER comes with and change the identifiers. I am not so sure of this.

zzo38computer 1y ago

For me too, although you only need to use (and implement) the parts which are relevant for your application and not all of them, so it is not really the problem. (I also never needed to write ASN.1 schemas, and a full implementation of ASN.1 is not necessary for my purpose.) (This is also a reason I use DER instead of BER, even if canonical form is not required; DER is simpler to handle than all of the possibilities of BER.)

jeroenhd 1y ago

The ASN.1 format itself is pretty well-suited for generic file types. Unfortunately, there are very few good, open source/free ASN.1 (de)serializers out there. In theory you could use ASN.1 DER files the same way you would JSON for human-readable formats. In practice, you're better off picking a different format. Modern evolutions of ASN.1 like ProtoBuf or Cap'n Proto designed for transmitting data across the network might fit this purpose pretty well, too. On the other hand, using ASN.1 may be a good way to make people trying to reverse engineer your format give up in despair, especially if you start using the quirks ASN.1 DER comes with and change the identifiers.

zzo38computer 1y ago
> Unfortunately, there are very few good, open source/free ASN.1 (de)serializers out there. I wrote a library to read/write DER, which I have found suitable for my uses. (Although, I might change or add some things later, and possibly also some things might be removed too if I think they are unnecessary or cause problems.) https://github.com/zzo38/scorpion/blob/trunk/asn1/asn1.c https://github.com/zzo38/scorpion/blob/trunk/asn1/asn1.c https://github.com/zzo38/scorpion/blob/trunk/asn1/asn1.h https://github.com/zzo38/scorpion/blob/trunk/asn1/asn1.h (You can complain about it if there is something that you don't like.) > In theory you could use ASN.1 DER files the same way you would JSON for human-readable formats. In practice, you're better off picking a different format. I do use ASN.1 DER for some things, because, in my opinion it is (generally) better than JSON, XML, etc. > Modern evolutions of ASN.1 like ProtoBuf or Cap'n Proto designed for transmitting data across the network might fit this purpose pretty well, too. I have found them to be unsuitable, with many problems, and that ASN.1 does them better in my experience. > On the other hand, using ASN.1 may be a good way to make people trying to reverse engineer your format give up in despair, especially if you start using the quirks ASN.1 DER comes with and change the identifiers. I am not so sure of this.