[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
How to legally circumvent the PGP 2.6 "legal kludge"!
How to legally circumvent the PGP 2.6 Legal Kludge.
According to the pgpdoc2.txt that comes with PGP 2.6:
>PGP version 2.6 can read anything produced by versions 2.3, 2.3a, 2.4,
>or 2.5. However, because of a negotiated agreement between MIT and
>RSA Data Security, PGP 2.6 will change its behavior slightly on 1
>September 1994, triggered by a built-in software timer. On that date,
>version 2.6 will start producing a new and slightly different data
>format for messages, signatures and keys. PGP 2.6 will still be able
>to read and process messages, signatures, and keys produced under the
>old format, but it will generate the new format. This incompatible
>change is intended to discourage people from continuing to use the
>older (2.3a and earlier) versions of PGP, which Public Key Partners
>contends infringes its RSA patent (see the section on Legal Issues).
This is the "legal kludge". However there is an undocumented PGP
parameter in PGP 2.6 which appears to be intended to allow the PGP
user to disable this "feature". This parameter may only be specified
on the command line using the "+" syntax. It is thought that it was
intended that one could disable this feature using a command like the
following:
pgp +legal_kludge=off -e file
However this does not work. In the source file config.c we find:
case LEGAL_KLUDGE:
legal_kludge = value;
break;
Since legal_kludge is a Boolean variable, the specified value "=off"
is in the variable "flag". Value usually has the wrong number, since
it is not set for Boolean values. Thus due to what appears to be a
bug, we can not use the "legal_kludge" parameter to disable the
kludge. Perhaps the bug is not really a bug at all, but a
feature. After all it does limit the interpretability of pgp 2.6 with
earlier versions.
We can not fix this bug without violating MIT's licensing
requirements.
>2. Software included in this compilation includes a feature that
>causes the format of messages generated by it to change on September
>1, 1994. Modification to this software to disable this feature is not
>authorized and will make this license, and the license in the
>underlying software, null and void.
If we were hell-bent to frustrate RSA and MIT, we would simply use
pgp26ui and not tell them about it rather than hack their sacred
kludge.
It would seem to be an impasse. Or is it? Note that value is declared
statically:
>static int value;
Every time a numeric parameter is parsed the variable value is used to
hold the number. So all we have to do is specify a numeric parameter
of zero before we specifying "legal_kludge"! We can then set that
parameter back to the desired value if zero is not desired. That is
the following works!
>pgp +cert_depth=0 +legal_kludge=off +cert_depth=4 -e file
The above assumes that we wish to use 4 as the value of cert_depth.
We set cert_depth to zero only to get the value of "value" to 0. The
the legal_kludge parameter will set the value of "legal_kludge" to be
=value=0, then we set cert_depth to the real desired value.
This trick is legal, because we have not modified pgp 2.6 in any way.
We are simply exploiting a bug or feature in the way PGP 2.6 is
written.
This kludge may seem to be too kludgy! It is asking a lot to ask users
to type such a thing! But is this really a problem? Most users do not
invoke PGP directly. They usually invoke PGP thru a mail program or
some other shell program. These shell programs can be easily modified
to do the right thing. In the worst case, people could define a shell
alias to invoke pgp with the incantation!
This discovery will allow people who must use PGP 2.6 to communicate
with people with earlier versions of PGP!
------------------------------------------------------------------------------
Paul Elliott Telephone: 1-713-781-4543
[email protected] Address: 3987 South Gessner #224
Houston Texas 77063
--