RE: Draft-11: More complete results

> -----Original Message-----
> From: Jim Schaad [mailto:[email protected]]=20
> 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 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 =3D 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 =3D 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 =3D 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 =3D 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 =3D 0x7B, 0xF1, 0x38, 0x25, 0xE9, 0x0F, 0xD8, 0xE5

CEKICV =3D 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 =3D 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 =3D 0xC0, 0xCA, 0x0F, 0x30, 0x3B, 0x86, 0x2E, 0x3D

computedICV =3D 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=C0EQL<-.=DAcP.=AE=D4=AC 0x0012F258  64 cc 95 ae af cd 0f 8c b6 48 1f=
 0b 45 12
> 4d fb d=CC.=AE=AF=CD..=B6H..E.M.
> 0x0012F268  a4 ab c7 83 30 4b 69 ad                         =A4=AB=C7.0=
Ki=AD
>=20
> Mail list key
> 0x00324354  25 5e 0d 1c 07 b6 46 df b3 13 4c c8 43 ba 8a a7
> %^...=B6F=DF=B3.L=C8C=BA.=A7 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
> =D7.f..B..b=A3.=DE=B5.N~ 0x00324640  5f 13 30 b5 13 d3 a8 4f be dc 02 d=
4 81 27
> db 50 _.0=B5.=D3=A8O=BE=DC.=D4.'=DBP
> 0x00324650  e5 d8 0f e9 25 38 f1 7b                         .=D8..%8.{

Same as TEMP3 from mine.

> IV
> 0x00324630  7b f1 38 25 e9 0f d8 e5                         {.8%..=D8.

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=DB'.=D4.=DC=BEO=A8=D3.=B50._ 0x00324640  7e 4e ef b5 de e5 a3 62 80 e=
0 42 9a ee 66
> 10 d7 ~N.=B5=DE.=A3b..B..f.=D7

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.>=CC..=CC=
=AF

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