home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / pc / crypto / legal_kl.txt < prev    next >
Encoding:
Internet Message Format  |  2003-06-11  |  4.0 KB
  1. From: paul.elliott@hrnowl.lonestar.org (Paul Elliott)
  2. Subject: How to legally circumvent PGP 2.6's legal_kludge!
  3. Date: Tue, 19 Jul 94 04:37:30 GMT
  4.  
  5. According to the pgpdoc2.txt that comes with PGP 2.6:
  6.  
  7. >PGP version 2.6 can read anything produced by versions 2.3, 2.3a, 2.4,
  8. >or 2.5.  However, because of a negotiated agreement between MIT and
  9. >RSA Data Security, PGP 2.6 will change its behavior slightly on 1
  10. >September 1994, triggered by a built-in software timer.  On that date,
  11. >version 2.6 will start producing a new and slightly different data
  12. >format for messages, signatures and keys.  PGP 2.6 will still be able
  13. >to read and process messages, signatures, and keys produced under the
  14. >old format, but it will generate the new format.  This incompatible
  15. >change is intended to discourage people from continuing to use the
  16. >older (2.3a and earlier) versions of PGP, which Public Key Partners
  17. >contends infringes its RSA patent (see the section on Legal Issues).
  18.  
  19. This is the "legal kludge". However there is an undocumented PGP
  20. parameter in PGP 2.6 which appears to be intended to allow the PGP
  21. user to disable this "feature". This parameter may only be specified
  22. on the command line using the "+" syntax. It is thought that it was
  23. intended that one could disable this feature using a command like the
  24. following:
  25.  
  26. pgp +legal_kludge=off -e file
  27.  
  28. However this does not work. In the source file config.c we find:
  29.  
  30.           case LEGAL_KLUDGE:
  31.             legal_kludge = value;
  32.             break;
  33.  
  34. Since legal_kludge is a Boolean variable, the specified value "=off"
  35. is in the variable "flag". Value usually has the wrong number, since
  36. it is not set for Boolean values. Thus due to what appears to be a
  37. bug, we can not use the "legal_kludge" parameter to disable the
  38. kludge.  Perhaps the bug is not really a bug at all, but a
  39. feature. After all it does limit the interpretability of pgp 2.6 with
  40. earlier versions.
  41.  
  42. We can not fix this bug without violating MIT's licensing
  43. requirements.
  44.  
  45. >2.  Software included in this compilation includes a feature that
  46. >causes the format of messages generated by it to change on September
  47. >1, 1994. Modification to this software to disable this feature is not
  48. >authorized and will make this license, and the license in the
  49. >underlying software, null and void.
  50.  
  51. If we were hell-bent to frustrate RSA and MIT, we would simply use
  52. pgp26ui and not tell them about it rather than hack their sacred
  53. kludge.
  54.  
  55. It would seem to be an impasse. Or is it? Note that value is declared
  56. statically:
  57.  
  58. >static int value;
  59.  
  60.  
  61. Every time a numeric parameter is parsed the variable value is used to
  62. hold the number. So all we have to do is specify a numeric parameter
  63. of zero before we specifying "legal_kludge"!  We can then set that
  64. parameter back to the desired value if zero is not desired. That is
  65. the following works!
  66.  
  67. >pgp +cert_depth=0 +legal_kludge=off +cert_depth=4 -e file
  68.  
  69. The above assumes that we wish to use 4 as the value of cert_depth.
  70. We set cert_depth to zero only to get the value of "value" to 0.  The
  71. the legal_kludge parameter will set the value of "legal_kludge" to be
  72. =value=0, then we set cert_depth to the real desired value.
  73.  
  74. This trick is legal, because we have not modified pgp 2.6 in any way.
  75. We are simply exploiting a bug or feature in the way PGP 2.6 is
  76. written.
  77.  
  78. This kludge may seem to be too kludgy! It is asking a lot to ask users
  79. to type such a thing! But is this really a problem? Most users do not
  80. invoke PGP directly. They usually invoke PGP thru a mail program or
  81. some other shell program.  These shell programs can be easily modified
  82. to do the right thing.  In the worst case, people could define a shell
  83. alias to invoke pgp with the incantation!
  84.  
  85. This discovery will allow people who must use PGP 2.6 to communicate
  86. with people with earlier versions of PGP!
  87. ------------------------------------------------------------------------------
  88. Paul Elliott                                  Telephone: 1-713-781-4543
  89. Paul.Elliott@hrnowl.lonestar.org              Address:   3987 South Gessner #224
  90.                                               Houston Texas 77063
  91.  
  92.