This is the home page of the Unofficial International family of PGP implementations, the latest of which is PGP 2.64ui, the successor to PGP 2.6ui, published by "mathew", 2.62ui,published by Tony Lezard, and 2.63ui, published by myself. The ui series is based originally on version 2.3a. This latest version is published by myself, Steve Crompton.
Please do not confuse this version with the (somewhat official) International version of PGP published by Stale Schumaker and described by The International PGP Home Page, which is based on PGP 2.6.2 published by MIT.
This version is being made available for a number of reasons:
Users inside the USA may not legally use 2.64ui, because the RSA patent is in effect there. USA residents are advised to obtain one of the MIT versions which have a license for non-commercial use of RSA.
However, I note in passing that by using the armor_version parameter in CONFIG.TXT, that armored output from PGP 2.64ui can be made difficult or impossible to distinguish from other versions.
Note that I personally have not done very much of the actual coding on this version. However if bugs are reported or constructive suggestions for improvements made I will pass them on to the individual(s) who have done the bulk of the work to make this release possible. I am assured that continuing support will be provided.
This site will also post any bugs or concerns that are brought to our attention and our comments.
This is a partial list of the changes and fixes since 2.63ui. A complete list is in file 264UICHG.ASC, which is inside both ZIP distribution files.
Some mailer systems will change a capital F in text to =46. Probably this is for recognizing "From" at the start of a new message and to insure a false indication of a new message does not occur. PGP 2.64ui contains code to automatically handle this situation and to avoid some crashes with other bad armortext.
PGP now checks for valid numeric parameters (e.g. VERBOSE=).
This is a partial list of the changes and fixes to 2.63ui since 2.62ui. A complete list is in file 263UICHG.ASC.
This will add readable text in front of an encrypted and armored file listing the public keys used to encrypt it. The format of the text is similar to what appears on the console during (-l) decryption.
When verifying the signature on a text (not binary) file, and a detached signature (-b) is not requested, PGP 2.63ui will prepend a message with the results of the signature verification (good or bad) similar to what appears on the console.
version_byte=3 is usually set to Emulate PGP 2.6 after 9/1/94
Version_byte must be set to 2 before encrypting/signing messages to be decrypted/verified by PGP 2.2 or 2.3a.
Also, unique to PGP 2.63ui, is the ability to set version_byte to 2 in extracted keys (-kx[a]). This allows PGP 2.63ui to extract keys which may have been created and/or signed by MIT PGP or by a ui version with version_byte set to 3 and create an extracted key which may be added (-ka) by PGP 2.3a.
Note that the reverse is not true. If version_byte=3, keys created with version_byte=2 are -not- changed when extracted.
Most disk writes are now checked for errors or running out of disk space.
Key Generation and other Keyring maintenance operations check for write access to public and (where required) secret keyrings before lengthy processing starts. Previous versions were not checking if the keyrings were set to read-only, which led to invalid results.
PGP 2.64ui is distributed in two ZIP files
pg264ui.zip [executables & documentation]
pg264uis.zip [source code & documentation]
Each zip file contains a MANIFEST signed by me which gives the MD5 digests of all other files within the ZIP. You can use the MD5SUM.EXE program included in pg264ui.zip to verify the MANIFEST (after using PGP to strip the signature).
Here is the MANIFEST for pg264ui.zip
Here is the MANIFEST for pg264uis.zip
This version of PGP has not been approved by MIT, Network Associates, or Phil Zimmerman. Please do NOT send any questions or bug reports about this version to either pgp-bugs at MIT, to Network Associates, or directly to Phil, but rather to me,
Steve Crompton <100645.1716@CompuServe.COM>
London, 9th May 1998