RC2 inconsistency
"Blake Ramsdell" <[email protected]> Mon, 11 Aug 2003 23:18:13 -0700
| Newsgroups | gmane.ietf.smime-examples |
|---|---|
| Message-ID | <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAfEjznq7QT0GfOsKw4dcJjQEAAAAA@brutesquadlabs.com> |
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