Werner Koch <wk(_at_)isil(_dot_)d(_dot_)shuttle(_dot_)de> writes:
Lindsay Mathieson <lindsay(_at_)powerup(_dot_)com(_dot_)au> writes:
break existing implementations and compatibility is one of the objectives
for the spec.
and why do we have identifiers for ElGamal, HAVAL or ECC ? This
would break existing implementations too.
An implementor is able within the OpenPGP spec I think to write an
openPGP implementation which is largely backwards compatible with
pgp-2.6.x.
I think the trick is to use the algorithm capability information in
the public keys for people you are sending encrypted messages to to
decide which algorithms you can use in your message, and which packet
formats they will understand.
Then, in addition you need to interpret a pgp-2.6.x formatted public
key as an implicit encoding of the fact that the sending application
can only cope with pgp-2.6.x packets, and only cope with algorithms
IDEA, MD5, and RSA.
I think this should work.
It gets tricky when your application is creating clear signed
signatures -- you don't know who the message is targetted at -- so to
follow the backwards compatibility reasoning to it's logical
conclusion this implies that all clear signed messages (or at least
those where you don't know who will later wish to verify them) should
only use MD5, and RSA.
This last option is not that attractive because:
a) RSA is a MAY cipher in openPGP due to patents;
b) MD5 is mildly depracted because of Dobbertins partial attack on it
being read as indicating the increased likelihood of stronger future
attacks;
c) MD5 has smaller output size than SHA1 the main alternative;
d) to use the approach it requires that the open PGP user HAS an RSA
key and several PGP Inc 5.x implementations do not support RSA, and
those that do support it do not automatically generate one at the same
time as the ElGamal/DSA keyset.
It would have been possible I think to hide an Elgamal/DSA key in a
pgp2.6.x format packet (for example in a comment field); using this
method we could have had full backwards compatibility. (A similar
trick is used in the move from SSLv2 to SSLv3.) (Similar kinds of
packet upgrades would have allowed backwards compatiblity for
signatures and encrypted information for multiple recipients with some
recipients being openPGP new algorithms over pgp-2.6.x).
However at this stage, doing this could not be made compatible with
existing PGP 5.x implementations, and it is kind of ugly, and the
directive of `limited backwards compatibility' it seems to me allows
you to draw the line at this kind of thing. It seems that pgp-2.6.x
formats were not designed with enough forward compatibility in mind to
allow doing this kind of thing without resorting to overloading
comment fields.
In summary IF the openPGP application chooses to implement the MAY
cipher RSA and the MAY cipher IDEA, then you can have backwards
compatibility with pgp-2.6.x.
This doesn't necessarily work with multiple crypto recipients, but we
already have problems with that: when one recipient can only cope with
IDEA because he has a pgp-2.6.x client, and another recipient has
implemented only the MUST options of openPGP you have no overlap in
cipher suite. (ie using 3DES no longer works because pgp-2.6.x can't
understand it, etc).
As a comment to Hal and Jon, I think that the PGP implementation could
use some improvement in the area of auto-detecting pgp-2.6.x and
reacting accordingly -- I receive messages from people using pgp-5.x
with RSA implemented, and the message is RSA and IDEA encrypted but
has (I think) DSA signatures contained even though the user also has
an RSA key. (Either that or is inserting a pgp5.x only packet which
otherwise throws pgp-2.6.x).
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`