[openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG

[Michael Heide]

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.

Thanks. 

(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
> input:
> 
> 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 
hash string.

[in int_rsa_verify() in crypto/rsa/rsa_sign.c using 
PKCS7_verify()]

> > 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.

me2

Maybe simply nobody thinks about it because it's accepted even by the 
brand-new Windows 10. Maybe because of *1 (see above).

regards
Michael