Hi all
I am having trouble decrypting S/MIME messages with openssl that were
generated in an application using the bouncycastle java-api.
I have tried the following:
# openssl smime -decrypt -in encMsgNOK.eml -inkey private.key
This results in:
Error reading S/MIME message
3073721992:error:0D06B08E:asn1 encoding routines:ASN1_D2I_READ_BIO:not
enough data:a_d2i_fp.c:238:
3073721992:error:0D0D106E:asn1 encoding routines:B64_READ_ASN1:decode
error:asn_mime.c:193:
3073721992:error:0D0D40CB:asn1 encoding routines:SMIME_read_ASN1:asn1
parse error:asn_mime.c:524:
Then tried to asn1parse the encrypted-only part (after removing the
MIME-Headers from the file):
# openssl asn1parse -in encMsgNOK.eml.copy
Which resulted in this output:
0:d=0 hl=2 l=inf cons: SEQUENCE
2:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-envelopedData
13:d=1 hl=2 l=inf cons: cont [ 0 ]
15:d=2 hl=2 l=inf cons: SEQUENCE
17:d=3 hl=2 l= 1 prim: INTEGER :00
20:d=3 hl=4 l= 387 cons: SET
24:d=4 hl=4 l= 383 cons: SEQUENCE
28:d=5 hl=2 l= 1 prim: INTEGER :00
31:d=5 hl=2 l= 103 cons: SEQUENCE
33:d=6 hl=2 l= 83 cons: SEQUENCE
35:d=7 hl=2 l= 11 cons: SET
37:d=8 hl=2 l= 9 cons: SEQUENCE
39:d=9 hl=2 l= 3 prim: OBJECT :countryName
44:d=9 hl=2 l= 2 prim: PRINTABLESTRING :CH
48:d=7 hl=2 l= 21 cons: SET
50:d=8 hl=2 l= 19 cons: SEQUENCE
52:d=9 hl=2 l= 3 prim: OBJECT :organizationName
57:d=9 hl=2 l= 12 prim: PRINTABLESTRING :SwissSign AG
71:d=7 hl=2 l= 45 cons: SET
73:d=8 hl=2 l= 43 cons: SEQUENCE
75:d=9 hl=2 l= 3 prim: OBJECT :commonName
80:d=9 hl=2 l= 36 prim: PRINTABLESTRING :SwissSign Personal Gold
CA 2008 - G2
118:d=6 hl=2 l= 16 prim: INTEGER
:CB918FB7197D28A15D644E422F21F6
136:d=5 hl=2 l= 13 cons: SEQUENCE
138:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption
149:d=6 hl=2 l= 0 prim: NULL
151:d=5 hl=4 l= 256 prim: OCTET STRING [HEX
DUMP]:84EB92B4CE620591A25AAEECA7417004AB76C11E49F5C5C66B2C8A0E3A5512FFD3454421481F113E3339125C476B5289A3AC31FDA84A9831F313DD8B880C8C4D13094FF61920B1A0A0CACD4BE3C7CCD053F8D7C981EB1CBAC368F731D4BAAB482D2FE10E8AE5966ADA044A3E36A817B1F738AE1D18C155429D2CFC7498BCC8824B86B1BFB59E80CE506EF2DA74E7CF57E4569D2627C347FCEE07AA38308C58EF68957AC7CA9914CF2A71C3ADB97F21E2B52F8414AC268BB1F4E1FBA55999220BC913839717D41D7AA5EA76956952413A280AAD06612B1C661181D5FA1CEDA35E40948E809ED181E05B658FDD5EE57AFEDC6CE8C0EFA47922B6E53E2265616198
411:d=3 hl=2 l=inf cons: SEQUENCE
413:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
424:d=4 hl=2 l= 20 cons: SEQUENCE
426:d=5 hl=2 l= 8 prim: OBJECT :des-ede3-cbc
436:d=5 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:5DD85744F31C579B
446:d=4 hl=2 l=inf cons: cont [ 0 ]
448:d=5 hl=4 l=1000 prim: OCTET STRING [HEX
DUMP]:FF377112001AA3C....
1452:d=5 hl=4 l=1000 prim: OCTET STRING [HEX
DUMP]:85FAFC9D313....
(7 blocks of similarly formatted Octet String hexdumps, 1000 Bytes each,
skipped):
....3DEF6A7A900E4A4
Error in encoding
3074877064:error:0D07209B:asn1 encoding routines:ASN1_get_object:too
long:asn1_lib.c:142:
I had a look at the base64-encoded data, and noticed that it ends neatly
in "AAAAAAAAAAAAA", which is the base64
representation of some null bytes.
I then created an encrypted S/MIME message to the same recipient
(certificate) with an openssl-based application, and of course the
message could be decrypted without issues ;-)
I then base64-decoded the data from both messages and converted it to
hex, so I could look at the actual encoding. The one big difference
between the encoding of the S/MIME part that cannot be decrypted
and the other one that can, is that many "constructed" DER encodings
produced in this case by bouncycastle, use the "indefinite" length octet
form and are all nested within each other.
The long array of Null bytes that I detected in the base64 encoding
actually are the "end of content" bytes from a series of multiply nested
sequences whose length is given in the indefinite form.
Actually, the above asn1parser output shows 5 structures with indefinite
length encoding, and there are exactly 10 Bytes of "00" at the end of
the hexdump, so all nested objects close there.
This seems to be a speciality of BC, because another sample encrypted
S/MIME that was allegedly created by BC
(http://marc.info/?l=openssl-users&m=120188244226210&w=2) shows similar
characteristics
(and also cannot be decrypted by openssl)
Another thing that caught my eye was the use of this strange Tag/Length
encoding in the above data: "A080" (described as "cons: cont [ 0 ]"
above) appears twice, once before the start of the second sequence and
later (byte 446) befor the start of the concatenation of
octet strings that openssl chokes on (is splitting the data like this in
1KB chunks actually common practice btw.?)
The Tag A0 denotes it as a context-specific, constructed tag, with Tag
identifier "0", and the length octet "80" says it has an indefinite length.
Tag number "0" makes it reserved for BER, and seems to identify it as
the first in a set of context-specific elements. But in the second case
at least, it is not nested within a SET definition, which makes the Tag
a bit questionable in my eyes. But I am not sure of my ground on that one.
Having come so far, I have no idea where to look further. Two of the
ideas I had were:
1)Is there a way to tell BC to always calculate the length and use the
definite length form?
2) Is it actually good to split the pkcs7-data into 1000Byte blocks and
rely on the receiving party to concatenate those, without giving any
hint to that fact in the encoding?
I know this was a long read, but still I would be very grateful for any
pointers ... if any ;-).
Kind regards
/markus
I do have the two messages at hand, but would rather not clutter the
list with attachments. They can be downloaded here:
http://xfer.ch/files/encMsgOk.eml.copy.txt
http://xfer.ch/files/encMsgNok.eml.copy.txt
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
