--- Saulius Krasuckas saulius2@ar.fi.lt wrote:
Hmm. I don't understand the code, but if I change (+) BYTE tooBig definition, then exceptions are gone, but return codes still differs in the output (|):
(snip)
I thought if there may be some sense in tuning tooBig value, then could it be done?
You may be right. I'll explain what some of these errors mean:
In ASN.1 encoding, the first byte is the tag, or type of the value that follows. 0x02 is an integer. The second byte, if the high bit is not set, is the number of bytes of the value. So for example,
0x02 0x01 0x01
is the integer value 1.
If the high bit of the length byte is set, then the value of the length byte & 0x7f is the number of length bytes that follow. So, in long form:
0x02 0x81 0x01 0x01
is also the integer value 1. 0x81 & 0x7f is 0x01, meaning one length byte follows. The length value is 0x01, meaning one integer byte follows.
So the tooBig test does the following: 0x02 0x84 0xff 0xff 0xff 0xff
This means it's an integer, with 4 length bytes, whose value are 0xffffffff. That means 0xffffffff bytes of integer value should follow (which obviously don't.) In WinXP, there's apparently a sanity check on this to say this is too big a value, without trying to read this many bytes. That's what the test is trying to show: CRYPT_E_ASN1_LARGE is returned for an "insane" value.
- tooBig[] = { 0x00, 0x84, 0xff, 0xff, 0xff, 0xfc };
| encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 8009310b
This is CRYPT_E_ASN1_BADTAG, which is true because the first byte is not a valid tag.
- tooBig[] = { 0x02, 0x84, 0xf0, 0xff, 0xff, 0xfc };
- tooBig[] = { 0x02, 0x84, 0xff, 0x0f, 0xff, 0xfc };
| encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 80093102
This is CRYPT_E_ASN1_EOD, "end of data." That could be useful.
- tooBig[] = { 0x02, 0x04, 0xff, 0xff, 0xff, 0xfc };
| encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 00000000
This is a valid integer, 0xfffffffc, and there's already a test case for these.
- tooBig[] = { 0x02, 0x80, 0xff, 0xff, 0xff, 0xfc };
| encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 80093103
This is CRYPT_E_ASN1_CORRUPT, the length (0 bytes) is invalid.
- tooBig[] = { 0x02, 0x83, 0xff, 0xff, 0xff, 0xfc };
| encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got c0000005
That's interesting too. 0x00ffffff bytes are supposed to follow, but an access violation is caught. So the WinME version catches some exceptions, but not all?
- tooBig[] = { 0x02, 0x84, 0x0f, 0xff, 0xff, 0xfc };
- tooBig[] = { 0x02, 0x84, 0xff, 0xff, 0xff, 0xfc };
| encode.c:313: Test failed: Expected CRYPT_E_ASN1_LARGE, got 80093106
That's CRYPT_E_ASN1_MEMORY, meaning out of memory. Weird, it must try to allocate this much?
Anyway, the WinME implementation is kind of strange buggy. Thanks for playing with it. I think accepting both CRYPT_E_ASN1_LARGE and CRYPT_E_ASN1_EOD, along with a value that results in CRYPT_E_ASN1_EOD, would be a useful fix. Do you want to patch it?
--Juan
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com