[openssl-users] openssl asn1parse -length

Tue Jul 24 09:41:02 UTC 2018

On 23/07/2018 16:56, Christian Böhme wrote:
> Hello all,
>
> I have been trying to find a way to ascertain that the contents of a file
> is a DER-encoded ASN.1 structure such as
>
> $ openssl version
> OpenSSL 1.0.2g  1 Mar 2016
>
> $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -i
>      0:d=0  hl=4 l= 978 cons: SEQUENCE
>      4:d=1  hl=2 l=   9 prim:  OBJECT            :pkcs7-envelopedData
>     15:d=1  hl=4 l= 963 cons:  cont [ 0 ]
>     19:d=2  hl=4 l= 959 cons:   SEQUENCE
>     23:d=3  hl=2 l=   1 prim:    INTEGER           :03
>     26:d=3  hl=3 l= 133 cons:    SET
>     29:d=4  hl=3 l= 130 cons:     cont [ 3 ]
>     32:d=5  hl=2 l=   1 prim:      INTEGER           :00
>     35:d=5  hl=2 l=  27 cons:      cont [ 0 ]
>     37:d=6  hl=2 l=   9 prim:       OBJECT            :PBKDF2
>     48:d=6  hl=2 l=  14 cons:       SEQUENCE
>     50:d=7  hl=2 l=   8 prim:        OCTET STRING      [HEX DUMP]:64C8DCE92BE6CF80
>     60:d=7  hl=2 l=   2 prim:        INTEGER           :0800
>     64:d=5  hl=2 l=  46 cons:      SEQUENCE
>     66:d=6  hl=2 l=  11 prim:       OBJECT            :id-alg-PWRI-KEK
>     79:d=6  hl=2 l=  31 cons:       SEQUENCE
>     81:d=7  hl=2 l=  11 prim:        OBJECT            :camellia-256-cbc
>     94:d=7  hl=2 l=  16 prim:        OCTET STRING      [HEX DUMP]:DC131C842F099909DF465439C1B06038
>    112:d=5  hl=2 l=  48 prim:      OCTET STRING      [HEX DUMP]:7BEFFB307D05C8242A040B371EEA3C6F59F082C415057BF5A71F67437B92668CEED9C46B0F57B4E4A077B1651892D9D5
>    162:d=3  hl=4 l= 816 cons:    SEQUENCE
>    166:d=4  hl=2 l=   9 prim:     OBJECT            :pkcs7-data
>    177:d=4  hl=2 l=  31 cons:     SEQUENCE
>    179:d=5  hl=2 l=  11 prim:      OBJECT            :camellia-256-cbc
>    192:d=5  hl=2 l=  16 prim:      OCTET STRING      [HEX DUMP]:995169EEF15C876E5F1A92DAF6A129D7
>    210:d=4  hl=4 l= 768 prim:     cont [ 0 ]
>
> Since the files to test are rather large, I'd be content with being able
> to have only the first couple of bytes inspected.  It would appear that the
> -length  option allows to do just that.  However, whatever argument specified,
> I get this:
>
> $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 4
> Error in encoding
> 140548547200664:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long:asn1_lib.c:157:
> $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 16
> Error in encoding
> 140076397213336:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147:
> $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 32
> Error in encoding
> 139879438956184:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147:
> $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 64
> Error in encoding
> 139887577974424:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147:
> $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 128
> Error in encoding
> 140008118994584:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147:
> $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 256
> Error in encoding
> 140518349809304:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147:
> $ openssl asn1parse -in ciphertext.der -inform DER -offset 0 -length 512
> Error in encoding
> 140042967262872:error:0D07209B:asn1 encoding routines:ASN1_get_object:too long:asn1_lib.c:147:
>
> etcpp.  The files to test are expected to be at least 512 bytes in size.
>
> What's the expected behaviour of the  -length  option, BTW?
>
Best option is to download the documents that specify the DER
(or BER) ASN.1 Encoding, which is the X.690 (2015) ITU-T
"recommendation" which was a freely downloadable PDF last time
I checked.

Note: For clarity, DER is basically the BER but using the
simplest byte sequence for everything.  BER can usually be
converted to DER without knowing the data format specification
(such as RFC2315 for EnvelopedData).

 From there, you can see that a DER (and BER) file is based on
the following structure, nested and/or repeated as necessary:

   TAG    An encoding of a data type number such as SEQUENCE
            or "OBJECT" (Actually an OID).
   Length Byte length of contents (Variable length length
            encoding, see X.690)
   Actual contents bytes according to TAG and specific data
            type such as pkcs7 or X.509 etc.  Binary encoding
            of each type is in X.690
   Repeat terminator if Length was the (BER only) indefinite
            code used when a program starts output before
            knowing the final length (See X.690)

For example, the one you show below is thus:
0x30 (TAG for SEQUENCE)
Some length value large enough to hold what follows, see X.690
   0x06 (TAG for OBJECT id)
   Any definite encoding of length = 9 bytes(127 possibilities)
   0x2A (The bytes of pkcs7-envelopedData=1.2.840.113549.1.7.3)
   0x86 .840
   0x48
   0x86 .113549
   0xF7
   0x0D
   0x01 .1
   0x07 .7
   0x03 .3
Rest not needed for identification of a pkcs7-envelopedData file.

Note that same length values can be encoded in more than one way
if the file is in BER format, as is often the case with PKCS#7
files.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded