On Tue, Aug 28, 2012 at 1:07 PM, Dr. Stephen Henson wrote:
>
> 0000 - ba 80 69 57 62 78 03 d4-57 3c 93 83 b9 86 f1 5a ..iWbx..W<.....Z
> 0010 - 35 23 58 3d
>
> This isn't a proper DigestInfo structure at all it's just presumably the raw
> SHA1 hash (as you can see from its length: 20 bytes). A proper DigestInfo
> would have the initial byte 0x30 (SEQUENCE tag). You could use the -asn1parse
> option to rsautl instead of -hexdump on a correct signature.
Great, thanks a lot. I've been able to reproduce this on the erroneous
messages as well, and a correctly signed message gives for example
openssl rsautl -verify -certin -inkey s.pem -in sig.der -asn1parse
0:d=0 hl=2 l= 33 cons: SEQUENCE
2:d=1 hl=2 l= 9 cons: SEQUENCE
4:d=2 hl=2 l= 5 prim: OBJECT :sha1
11:d=2 hl=2 l= 0 prim: NULL
13:d=1 hl=2 l= 20 prim: OCTET STRING
0000 - 42 f7 3b c1 41 4f 04 e9-ac f3 4c 1f 33 3f de 73 B.;.AO....L.3?.s
0010 - e3 d9 e8 76 ...v
Could you confirm which RFC is violated by that missing DigestInfo
structure, RFC 2315?
I'd like to inform the author of the crypto module that their output
isn't correct (until now they deny that).
Any ideas why Outlook (for example) accepts this malformed signature?
Is there some alternate RFC/RFC version/format/..., which allows this
kind of raw data (or is it maybe just more "fault tolerant" on the
structure)?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
