RE: Draft-11: More complete results

Blake,

I don't know what I dumped the first time, but I now get the same CEKICV
as you do.

jim

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