RE: RC2 inconsistency

I concur that this is what happens.

I had just transcribed the key from the examples draft and there had
previously posted that I could decrypt 6.7 but not 6.9.  If I use the
key with the CRLF included in the middle of things then I can decrypt
example 6.9.

jim

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> Blake Ramsdell
> Sent: Monday, August 11, 2003 11:18 PM
> To: [email protected]; 'Paul Hoffman / IMC'
> Cc: 'Jim Schaad'
> Subject: RC2 inconsistency
> 
> 
> 
> I was just about to call it a night, thinking that all was 
> right in the universe of key wrapping...
> 
> It appears that I quite unintentionally used two different 
> RC2 keys to decrypt example 6.7 and 6.9.  The two keys are:
> 
> (transcribed from the examples draft) b7 0a 25 fb c9 d8 6a 86 
> 05 0c e0 d7 11 ea d4 d9
> 
> (from the extracted MailListRc2.bin)  b7 0d 0a 25 fb c9 d8 6a 
> 86 05 0c e0 d7 11 ea d4 d9
> 
> Notice the CRLF translation...
> 
> Now, I would say that this isn't a problem, except for the 
> fact that example 6.9 appears to require the CRLF version and 
> example 6.7 requires the other one!
> 
> I have tried to monkey with extracting the base64 data for 
> MailListRc2.bin using other code, and I get the CRLF in that 
> case also. I have attempted to extract this on three 
> different Oses, and each of them has the CRLF, so I believe 
> that this is in the encoded data.
> 
> So the bottom line seems to be:
> 
> 1. The encoded file MailListRc2.bin needs to be corrected to 
> match the printed version in the draft.
> 
> 2. Example 6.9 will then be incorrect, and the kekri will 
> need to be regenerated for this example.
> 
> It would be good to have some confirmation of this, if anyone 
> can check on their side.
> 
> Blake
> --
> Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com 
>