How to create an ASN.1 DER-encoded blob simply

Greetings,

How can I simply encode some binary data into an ASN.1 DER-encoded blob? I'm using C/C++, and I figure it should be possible to simply prefix the binary blob with some appropriate bytes that signify that the data is of type octet string and is of a given length (and in a sequence of length 1 I guess).

Background if you're interested:

Why do I want to abuse ASN.1 in this way? For a research project, I need to embed some data in a digital signature that has an associated an X.509 certificate. (I'm using createSignatureEx in Peter Gutmann's cryptlib library to create CMS / S/MIME-2/3 / PKCS-#7 compliant signatures if it matters. I'm not signing the data I want to encode, just adding it as metadata to the signature to enrich it.) According to my understanding, serious signatures with arbitrary extension data require the extension data to be encoded using ASN.1 DER. My data is a binary blob and is only useful to my application, so there's no real value in doing proper ASN.1 encoding of each part of my data. I figure with some work I could learn t开发者_如何学编程o use asn1c to do this, but it looks pretty complicated and I'm on deadline. Equally importantly, it seems unnecessary and it seems like this information could be useful to other developers who want to avoid the pain of proper ASN.1 encoding.

Thanks!

I would use the ASN.1 Compiler.

People abuse ASN.1 because it is a way to encode data structures. Any time you have a C/C++ program working with a data structure that the attacker controls problems like; buffer overflows and integer overflows, come into play. ASN.1 is no more insecure than lets say XML or JSON or bencode, as these are all likely points of failure. There can be problems with the encoding library its self, like this nasty Microsoft vulnerability. But this statement is true regardless of the encoding method you use. ASN.1 is a great choice because the resulting message is extremely small and it is the most efficient use of space of any encoding method that I know of.

You can't just append a blob of ASN.1 to an X.509 certificate and expect it to become part of the certificate. The certificate is an ASN.1 SEQUENCE of values, and as such it starts with a SEQUENCE tag and a length, which encompasses all of the certificate.

If you want to add a field to the certificate structure (which will probably mean that it is no longer a valid certificate, but it could still be a valid ASN.1 structure) then you will have to change the length of that enclosing sequence as well as appending your data.

Yes, 04 08 01 23 45 67 89 ab cd ef is a valid DER encoding of an octet string. The 04 at the beginning is the tag for OCTET STRING and the 08 is the length of the string. Note that lengths up to 127 are encoded in one byte and that larger lengths use a longer encoding.

For a good introduction to ASN.1 -- and especially to its use in cryptographic messages -- see "A Layman's Guide to a Subset of ASN.1, BER and DER", which you should be able to find on the rsa.com site.

I would suggest to use Quick DER, and feed its der_pack() routine with a structure description that you can compile with its asn2quickder compiler. If it's a matter of using a standard structure you can probably just #include <quick-der/rfc5280> and use its predefined data.

You can use der_unpack() for unpacking with the same structural description. It will validate structural aspects, though not the constraints that ASN.1 syntaxes may incorporate. Integer ranges are checked when you use the utility functions that put and get them.

Sorry to be pushing my onw library; but it was actually written for the purpose of easily accessible ASN.1 for (open source) C/C++ and Python developers.