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
