A small bit of historical context. When I was participating in the PKP meetings at RSADSI, I believe it was Ron who insisted that DER was the only reasonable choice if we were going to encode things with ASN.1 (which we were because both DEC and RSA had already insisted that it had to be OSI compatible or they wouldn't support it, my suggestion that we use Sun's XDR was soundly rebuked, but hey I had to offer)<p>Generally it was presumed that because these were 'handshake' type steps (which is to say the prelude to establishing a cryptographic context for what would happen next) performance wasn't as important as determinism.
I was writing a cryptographically-inclined system with serialization in msgpack. At one point, I upgraded the libraries I was using and all my signatures started breaking because the msgpack library started using a different representation under the hood for some of my data structures. That's when I did some research and found ASN.1 DER and haven't really looked back since switching over to it. If you plan on signing your data structures and don't want to implement your own serialization format, give ASN.1 DER a look.
There is also rasn library for Rust that now supports most of the codecs (BER/CER/DER/PER/APER/OER/COER/JER/XER).<p>Disclaimer: I have contributed a lot recently. OER codec (modern flair of ASN.1) is very optimized (almost as much as it can be with safe Rust and without CPU specific stuff). I am still working with benchmarking results, which I plan to share in close future. But it starts to be the fastest there is in open-source world. It is also faster than Google's Protobuf libraries or any Protobuf library in Rust. (naive comparison, no reflection support). Hopefully other codecs could be optimized too.<p>[1] <a href="https://github.com/librasn/rasn">https://github.com/librasn/rasn</a>
Related: if you ever want to create your own serialization format, please at least have a cursory look at the basics of ASN.1. It's very complete both in terms of textual descriptions (how it started) and breadth of encoding rules (because it's practical.)<p>(You can skip the classes and macros, though they are indeed cool...)
Erlang also has great ASN.1 support. For the rest, I hope OSS Nokalva'a proprietary solutions will go away, eventually.<p>For Java I used yafred's asn1-tool, which is apparently not available anymore. Other than that, it worked well.<p>Originally it was available here: <a href="https://github.com/yafred/asn1-tool">https://github.com/yafred/asn1-tool</a> (archived: <a href="https://web.archive.org/web/20240416031004/https://github.com/yafred/asn1-tool" rel="nofollow">https://web.archive.org/web/20240416031004/https://github.co...</a>)<p>Any recommendations?
DER is still easy, UPER (unaligned packed encoding rules) is so much harder, yet it's prevalent in Telecom industry.
Last I checked, there was no freely available tool than can handle UPER l00%
neat!<p>related: you can also create wireshark dissectors from ASN.1 files<p><a href="https://www.wireshark.org/docs/wsdg_html_chunked/ASN1StepByStepInstructions.html" rel="nofollow">https://www.wireshark.org/docs/wsdg_html_chunked/ASN1StepByS...</a>
I do not use Python, but I wrote my own library in C for reading/writing DER. (I have made a variant, which adds a few new types such as: key/value list, BCD, TRON character code, etc. The program works even if you do not use these new types.)<p>DER does have the advantages they mention in that article, and other advantages.<p>Some people mention that DER is not compact or not efficient; but often what is used instead is formats that are even less compact or less efficient than DER, and/or that are significantly more complicated to handle.
Parser differential exploits are a understated problem, especially with ASN.1, which I didn't expect to see anyone thinking about. Kudos on this initiative!
From the post<p>> with the help of funding from Alpha-Omega<p>From the site:<p>> funded by Microsoft, Google, and Amazon<p>Also it's a Linux Foundation project.<p>Interesting. Python's a big community, and there's some disagreement here over whether this would be better done in pure python. I think it's good that there's a rust/cloud contingent in python land but hope pure python remains popular.
Oh right, the asn1 crate, which supports CHOICE but only up to 3 alternatives, which means it can't even be used to implement X.509 certificate decoding. Makes me wonder what they're going to do when they get that far.
20+ years ago used ASN.1 for talking between micro services. (HTTP Services, as they were called then) Very performant.
Had to buy OSS tools licence but other than that quite nice.
Does anyone miss when "pure python" was a selling point of your library? I understand the need for speed, but I wish it were more common to ship a compiled binary that does the thing fast, as well as the same algorithm in python to fall back on if it's not available.