Uri writes:
However i think the functionality list has a gap: it doesn't cover
that many people will want to continue using IDEA, 3DES, blowfish.
There will remain no way to prevent message modification for unsigned
messages for these.
It is bad enough to have to be compatible with the existing
"old" methods - it will be far worse to have to in addition
be compatible with "new old" methods. Enough is enough.
We had plenty of warning about the MDC issue. The issue was discussed
on this list over a year ago (Jan 98). Even before that Gary Howland
presented the problem at Hip in Aug 97. If I recall at the time ita
was reported that PGP made a press release or some kind of public
statement saying they had a fix for the problem. We have a recently
released rfc2440 and people are now finally talking about fixing the
MDC problem, yet they want to do it in ways which rfc2440
implementations can't benefit from.
Now if one adds to PRZs functionality list that we want this to be
backwards compatible so that non-large ciphers can use it, you need a
way to send a MDC inside an encryption envelope such that it won't
cause current implementations to barf. For this the appended hash
method doesn't work (or at least I can see no elegant way to make it
work).
A good enough reason for me to vote down the support for MDC in
"old" ciphers.
Not really, the symmetric MDC packet is more elgant, as well as
providing the possibility of working with the existing RFC, and so
provides more overall security. We only just finished writing 2440,
and you want to start obsoleting it.
There are I think more pgp2.x implementations than 5.x, 6.x and GPG
together.
I think your comments about ease of implementation are off-base -- Tom
Zerucha, who wrote an OpenPGP implementation votes that symmetric MDCs
are easier. I haven't implemented OP, but I have implemented parts of
pgp2.x, and I think this change would be easier also. It fits right
into the existing framework, and doesn't require buffering tricks.
I argue that these benefits make it worth favoring the new signature
type over appended hash approach.
Let's say that we disagree here.
Perhaps if we could list the pros and cons:
- ease of implementation (MDC sig wins)
- adds security for more implementations (MDC sig wins)
What are your arguments against MDC sigs?
Note I am not against the "big clean up" phase planned for openPGP
2.0. I am all for it. I think PRZs suggestion that we add a new
encryption method (standard CFB etc) is a _good thing_. However I
would sooner see MDCs implemented in a way which fits into the
existing framework, and thus is backwards compatible! That's what the
framework is for -- so that there are defined means for algorithms to
get added. Therefore I argue you should do what you can, especially
when it is more elegant anyway, within the existing framework.
Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`