3 ms·
Often you don't have a choice but to write your own parsers for serialization formats, as inter-language & inter-tool interoperability is still not very good, e
by ThePhysicist 5y ago
Often you don't have a choice but to write your own parsers for serialization formats, as inter-language & inter-tool interoperability is still not very good, except maybe for TLS-related stuff. There's e.g. no predefined way to verify an ECDSA signature created in JS using Golang (or vice versa), so you have to parse the R & S values by hand. Luckily they are just concatenated big-endian numbers.
- lu4p 5y agoI'm pretty sure there is https://pkg.go.dev/crypto/ecdsa#Verify https://pkg.go.dev/crypto/ecdsa#Verify
- ThePhysicist 5y agoThat's exactly what I referred to: The function takes two BigInt's, which you have to unpack yourself from the byte-serialization created by JS. There's no JS-compatible ECDH key derivation function in Golang either, so you have to implement the multiplication yourself (which again isn't difficult).
- dcow 5y agoMy impression is that crypto people, being mildly allergic to asn.1, decided not to use it to specify standard serialization formats in our new world of EC crypto. So here we are without asn.1 and without a replacement. I generally think if you’re going to remove something because you think it sucks it’s on you to replace it with an equivalent or clearly justify why it was vestigial if you don't have one. In this case you really don't need a DER calibre encoding either, you just need a standard in the first place. It’s just that the standard would historically likely use asn.1. But that doesn't have to be the case. Maybe the closest thing is the ECDSA point form specified in https://www.secg.org/sec1-v2.pdf#page16 https://www.secg.org/sec1-v2.pdf#page16. The the curve domain parameters in sec2 are, you guessed it, specified in asn.1.
- johnisgood 5y agoASN.1 is quite amazing but my only experience with it is through Erlang. The Erlang implementation of it is pretty damn good.