-----Original Message-----
From: Blake Ramsdell [mailto:blake(_at_)brutesquadlabs(_dot_)com]
Sent: Saturday, August 09, 2003 1:17 AM
To: jimsch(_at_)exmsft(_dot_)com; 'Ietf-Smime-Examples';
ietf-smime(_at_)imc(_dot_)org; 'Paul Hoffman / IMC'
Cc: 'Sean P. Turner'
Subject: RE: Draft-11: More complete results
-----Original Message-----
From: Jim Schaad [mailto:jimsch(_at_)nwlink(_dot_)com]
Sent: Wednesday, August 06, 2003 2:30 PM
To: 'Ietf-Smime-Examples'; ietf-smime(_at_)imc(_dot_)org; 'Paul Hoffman /
IMC'
Cc: 'Sean P. Turner'; Blake Ramsdell
Subject: Draft-11: More complete results
6.11 FAILED
test vectors are appended below on this message. I
don't know where
I am going wrong and this code worked in the past.
The bad news is, I can't get this example to work either.
The good news is that I have written a new implementation,
and it could very well have some kind of problem. I have
only tested my implementation against the test vectors in RFC 3217.
These are the results that I got with this example, using the
terminology from RFC 3217 section 3.2 wherever possible:
<lotsofboringhexdump>
wrappedKey = 0x74, 0x31, 0xC0, 0x45, 0x51, 0x4C, 0x3C, 0x2D,
0x2E, 0xDA, 0x63, 0x50, 0x8B, 0xAE, 0xD4, 0xAC, 0x64, 0xCC,
0x95, 0xAE, 0xAF, 0xCD, 0x0F, 0x8C, 0xB6, 0x48, 0x1F, 0x0B,
0x45, 0x12, 0x4D, 0xFB, 0xA4, 0xAB, 0xC7, 0x83, 0x30, 0x4B, 0x69, 0xAD
TEMP3 = 0xD7, 0x10, 0x66, 0xEE, 0x9A, 0x42, 0xE0, 0x80, 0x62,
0xA3, 0xE5, 0xDE, 0xB5, 0xEF, 0x4E, 0x7E, 0x5F, 0x13, 0x30,
0xB5, 0x13, 0xD3, 0xA8, 0x4F, 0xBE, 0xDC, 0x02, 0xD4, 0x81,
0x27, 0xDB, 0x50, 0xE5, 0xD8, 0x0F, 0xE9, 0x25, 0x38, 0xF1, 0x7B
TEMP2 = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5, 0x50,
0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F, 0xA8, 0xD3,
0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF, 0xB5, 0xDE,
0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE, 0x66, 0x10, 0xD7
TEMP1 = 0x50, 0xDB, 0x27, 0x81, 0xD4, 0x02, 0xDC, 0xBE, 0x4F,
0xA8, 0xD3, 0x13, 0xB5, 0x30, 0x13, 0x5F, 0x7E, 0x4E, 0xEF,
0xB5, 0xDE, 0xE5, 0xA3, 0x62, 0x80, 0xE0, 0x42, 0x9A, 0xEE,
0x66, 0x10, 0xD7
IV = 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5
CEKICV = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74,
0x37, 0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41,
0x19, 0x0F, 0x38, 0x47, 0x25, 0x2E, 0xC0, 0xCA, 0x0F, 0x30,
0x3B, 0x86, 0x2E, 0x3D
CEK = 0x51, 0x1B, 0x27, 0x0E, 0xE8, 0xEA, 0x33, 0x74, 0x37,
0xA5, 0x7D, 0xC7, 0xCC, 0x9B, 0x24, 0xCE, 0x32, 0x41, 0x19,
0x0F, 0x38, 0x47, 0x25, 0x2E
ICV = 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D
computedICV = 0x53, 0xFB, 0x3E, 0xCC, 0x8A, 0x06, 0xCC, 0xAF
</lotsofboringhexdump>
Mapping your results onto mine:
Wrapped key
0x0012F248 74 31 c0 45 51 4c 3c 2d 2e da 63 50 8b ae d4 ac
t1ÀEQL<-.ÚcP.®Ô¬ 0x0012F258 64 cc 95 ae af cd 0f 8c b6 48
1f 0b 45 12
4d fb dÌ.®¯Í..¶H..E.M.
0x0012F268 a4 ab c7 83 30 4b 69 ad ¤«Ç.0Ki
Mail list key
0x00324354 25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7
%^...¶Fß³.LÈCº.§ 0x00324364 1f 02 5b 7c 08 38 25 1f
We're on the same page here. I did not dump my Mail list
key, but there are many problems I would have later if these
weren't the same. Specifically, the next item would not match.
After decrypt #1
0x00324630 d7 10 66 ee 9a 42 e0 80 62 a3 e5 de b5 ef 4e 7e
×.f..B..b£.Þµ.N~ 0x00324640 5f 13 30 b5 13 d3 a8 4f be dc
02 d4 81 27
db 50 _.0µ.Ó¨O¾Ü.Ô.'ÛP
0x00324650 e5 d8 0f e9 25 38 f1 7b .Ø..%8.{
Same as TEMP3 from mine.
IV
0x00324630 7b f1 38 25 e9 0f d8 e5 {.8%..Ø.
Same as my IV also.
Post Decrypt #2
0x00324630 50 db 27 81 d4 02 dc be 4f a8 d3 13 b5 30 13 5f
PÛ'.Ô.ܾO¨Ó.µ0._ 0x00324640 7e 4e ef b5 de e5 a3 62 80 e0
42 9a ee 66
10 d7 ~N.µÞ.£b..B..f.×
This should theoretically be the same as my CEKICV (which is
the output of the second decryption), but it's not. This
appears to be the same as my TEMP1 which is the input to the
second decryption, not the output.
Computed check sum
0x0012EFD8 53 fb 3e cc 8a 06 cc af S.>Ì..̯
Same as my computedICV above. What I can't figure out is how
we both arrived at the same checksum with such different
answers for CEKICV (your "Post Decrypt #2"). My
understanding is that it's the first eight bytes of the sha-1
digest of the first 24 bytes of my CEKICV and your "Post Decrypt #2".
Actual Check sum
80 e0 42 9a ee 66 10 d7
This does not match my ICV above, but it matches the eight
bytes at the end of your "Post Decrypt #2".
I would hazard a guess that there is an error in one of our
implementations where the input and the output of the second
decryption step are being mistakenly interchanged. I have
checked mine and run the test vectors from RFC 3217 through
it, and I can't see the problem on my side. Now, I've said
this kind of thing before and been wrong, so take it with a
grain of salt...
In any case, in my test, this example is broken also, but
unless Jim and I can agree on an answer, it could be the case
that both of our implementations are broken.
Blake