[openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG
michael.heide at student.uni-siegen.de
Tue Sep 15 06:06:44 UTC 2015
Am Mon, 14 Sep 2015 21:01:49 +0200 schrieb Jakob Bohm <jb-openssl at wisemo.com>:
> > Seems to be a file with the same criteria here.
> That one is a big surprise to me.
(if it's a surprise to you, then it's ok to be a surprise for me too. ;-) )
> It seems that as late as in August 17 2015 (4 weeks ago),
> Symantec/Verisign issued a timestamp signature, whose
> "EncryptedDigest"was made on the following non-standard
> 00|01|FF...|00|00 87 34 69 20 D5 4C 68 F4 B1 30 6DEA 3E 40 CC B7 71 AC 1D
> The first parts (00|01|FF...|00) form the PKCS#1 padding
> for a PCS#1 v1.x signature.
> But the last part is a 20 byte string that doesn't seem to
> match anything permitted by PKCS#1 v1.5 (or v2.1). I also
> note that the SignerInfo specifies "version 1" (aka PKCS#7
> v1.5), so I don't think this could be the elusive PKCS#7
> v1.4 signature format.
> It might hypothetically be an SHA1 SUM, but the initial 00
> byte looks strange.
That's life. sha1 sums can start by any value between 00 and FF.
By change the sha1 sum can even be all 00. Would simply be a remarkable
coincidence. I have several other files of this type here and
this is the only one starting with 00.
That means: the corresponding hash value calculated in
EVP_VerifyFinal() also starts with 00.
> I am struggling a bit with trying to figure out what bytes
> are covered by the hash value, so far I have failed to
> manually extract a relevant subset of of the message, but I
> may have made some basic mistake since I usually don't do
> this by hand.
Me neither. I use gdb and/or add debug output to OpenSSL.
the full hash:
00 87 34 69 20 D5 4C 68 F4 B1 30 6D EA 3E 40 CC B7 71 AC 1D
calculated via EVP_DigestFinal_ex() by EVP_VerifyFinal()
called from PKCS7_signatureVerify() where the authenticated
attributes and their "content digest" is taken into account.
(=> This is a calculated value and not extracted from EncryptedDigest.)
> Well, the good news is that at least the PKCS#1 padding is
> still there, which makes it a lot less vulnerable than what
> your e-mails made me think.
ok, sounds good. Maybe that's the reason for *1 (see below):
It seems they think there are no known security drawbacks!?
Like I said: OpenSSL can handle it like every other PKCS#7
until it tries to decode the decrypted "EncryptedDigest"
via d2i_X509_SIG(), which fails on those non-ASN.1 plain
[in int_rsa_verify() in crypto/rsa/rsa_sign.c using
> > No, I'm not. Maybe I'm doing something wrong. I don't know.
> It seems not, now I really wonder what is going on.
Maybe simply nobody thinks about it because it's accepted even by the
brand-new Windows 10. Maybe because of *1 (see above).
More information about the openssl-users