Re: Question about MDC Packets

[Len Sassaman <[e-mail]>]

On Mon, 22 Jul 2002, Jon Callas wrote:

> Do you know anything about who is going to be decrypting it? Do you have
> some reasonable expectation they can understand it? If so, then yes.
>
> There is nothing wrong with an implementation being somewhat weasely. If you
> make the guess that if someone wants to use AES, then the target is modern
> enough to understand an MDC, you'd probably be right. You could even
> convincingly harumph if someone does *not* use an MDC but went to the
> trouble to do AES.

Okay, hear me harumph.

We're in the process of adding AES and MDC support to Mixmaster. I need to
decide whether to we want to go the "be liberal... but conservative" route
and only use MDC if specified in the features subpacket, or the more
secure route, and use MDC whenever a key lists prefs 7 through 10
(presumably, we could do this even if we weren't actually choosing those
ciphers for encryption, i.e. if CAST5 was listed first). I'd prefer to do
it in the latter fashion, but...

I just read over the source code for Hushmail's OpenPGP features. It
appears that they were working off of RFC2440-bis2, and therefore didn't
know anything about the MDC packets. Hushmail keys are generated with
symmetric cipher prefs "9 8 7 3".  Consequently, Hushmail users cannot
decrypt messages encrypted with AES using the MDC packet. An example key
is attached at the bottom of this email.

It would be unfortunate to have more compatibility problems between
implementations of OpenPGP. Would it be unreasonable to state in the spec
that implementations supporting ciphers other than 0 through 4 SHOULD be
able to handle the MDC packets (perhaps in the paragraph in 5.13 which
mentions AES and Twofish currently)?

This would place the burden of maintaining compatibility on the side of
the less secure implementation.

--Len.


-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: Hush 2.1

mQGiBD1kYTwRBACmS12GxIjVhkhLV/V+42S6RgcJWUyBsx0cIQJ0b6wBiKCODrjMXkqL
jeoKRj+CH3ZMKNpjyQMz/iUik93YHMKpfZ7tmZcx+08jvHI01xM83N6dAORA/nc7ZIsj
+AUHAiHOopKFOIg8MdBkaqZr9jMSZ5qZeKknm1c2ctifGPWpnQCgwANjll5Dj7tv/E1d
vCMn2dB1nQUEAJC4A/bdjL23jMdPfaYv6c8dV0LwRzDp25RltF6aKKXDRhsezxpjFray
RDr5WSh9A0M6AGnCMSfN4cQHTI7EiTHYVKztwfwjriedDR4m5EOLG3fIeo+89BDvjI0R
TLsCXoCfmJBJkZzHvXYn/23AjuoomPD54abjp9hzWA5Jt2AaA/98vK8hWby93JzgG4kz
NSGpiVssB2irMWsR9992cTvdjUbTasTFT9snUgETKBEgyAuYEOoC/gXagSe7Ito5o4/v
nvO7o+/AKPmGMA49ETW+lK3z4Ed2L7p96qBVisc8Ug/zbauVTnuvmdFiee2/Y88SUjQJ
mnkP4k0+6vOwBKZvwsJhBB8RAgAhBQI9ZGE8AgcBFwyAEYpgZW/CY0uc2qKnPHoC+ecn
TLYpAAoJEBen9nyD3MdaIeQAn1a1yCdMeLhSlqjEXZtJlwNT9nxIAJ44VZxfhVWs1KbK
9Ov9fF18q4B8gbQVbWRjLXRlc3RAaHVzaG1haWwuY29twlkEExECABkFAj1kYTwFCQHh
M4AFCwkIBwMCFQIDFgEAAAoJEBen9nyD3MdaeTAAn3ejME+kaVxKdSd5Cx9KZoM/ryzG
AJ4j/L6f1t7tL/4eiyyqpqtHX6UXncJsBBMRAgAsBQI9ZGE9AxYBAAUbAAAAABscSHVz
aCBDb21tdW5pY2F0aW9uIERFTU8gQ0EACgkQegL55ydMtikvKACeIH1FpdKVH5/un1Nr
v26ObkWPH7EAn1hm9SKWtyPEN2q0sj/znMOmASUHuQINBD1kYTwQCAD2Qle3CH8IF3Ki
utapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfU
odNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT
W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kj
wEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnI
Byl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7AAICB/4mK26O
lB/hsdZzk7mqwfh4dU6JJYR1zWcLUys8HtCr9Ou/oN5vdJfsPyFUllg60jj9lAE935TR
t67U/Nt666B1IqjWtOPyN/HGxZrIyd91YG4m5K/UvP1vmrc7AH/LhLYrSN+tLtIsW9yx
teMlPkKJc8+8LueKK/0f+vDCRiEP4G0MAG64KZWh2/wVYcJckLCety6qlQm7Z3Ckym2H
qosyRA7KtGBy7pNvw1Q5niSNSoWI8QOKme8f0QZ62ZxrvYk49zLSMRlW5iSNZOxYnWZA
lo4vFX5yugT3I2pBRBj3RC5pfJJjK3iemePC2NaIOA3nZSb2ZhLm/i4ZiD90YdO4wkwE
GBECAAwFAj1kYTwFCQHhM4AACgkQF6f2fIPcx1omigCgl5/aYzHDQ1BWlkXI6LpiQs2N
sykAnjaYqw9axQLzJci/PNQTnjvvyfXc
=sHIm
-----END PGP PUBLIC KEY BLOCK-----