On 15/09/2015 08:06, Michael Heide wrote: > 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. Yes, it was just rare enough to make me suspicious. >> 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.) Of cause, my problem was what bytes to pass to the digestion process, I couldn't find the right subset, even after double checking the PKCS#7 spec and trying different interpretations of the standard text. >> 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!? Where is *1 ? > > 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()] Of cause, this error is really at the PKCS#1 level, even though the PKCS#7 standard formally repeats that particular part of PKCS#7 due to ISO/OSI/ITU fun with BIT STRING vs. OCTET STRING notation. >>> 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). Yep, it is probably also accepted by Microsoft's generic PKCS#7 code, since I have in the past checked timestamps from that server in that way and not noticed the deviation. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20150915/6cf27e03/attachment-0001.html>
