-----BEGIN PGP SIGNED MESSAGE----- This is the Sanitized Build of C-KT PGP, it is based on the v5.5.3 source code released by PGPi.com. It has all the features of the regular C-KT PGP build save for the experimental ones. It adheres strictly to the standard set in the plain vanilla RSA enabled release of PGP 5.5.3 as far as key generation and use. A fresh set of source code was used, and all the non experimental features of the regular build of C-KT PGP were ported to this build. The following are the features that have been implemented so far: ************************************************************* * FEATURES IN THIS BUILD - 10 OCTOBER 1998 ************************************************************* * 1) Expanded list of key servers. * 2) Enhanced signing key dialogs, with DS key size & key id info. * 3) Key ID column in recipient dialog. ***NEW*** * 4) Enhanced PGPLog with key ID column. * 5) Enhanced decrypt dialog with more key information. * 6) Root directory problem fixed. * 7) User selectable number of key rings backups. * 8) Wipe function fixed. * 9) Floppy disk prompt when keyring is on diskette. * 10) Auto signing key id and fingerprint in comment block. * 11) User defined / selectable version string. * 12) Enhanced Explorer context menu. ***NEW*** * 13) Expanded pre-defined key sizes in key search dialog. ***NEW*** * 14) Expanded quick links in about dialog. ***NEW*** * 15) A message from Philip Zimmermann regarding large keys is * enclosed. ************************************************************* ** I urge all users to read the message from Philip Zimmermann regarding large keys (Please See Below). I have added some key servers, namely, PGP.ai.mit.edu, PGP5.ai.mit.edu (Bal's Key servers), and those of the PGP.net. The default server in this build is: Idap://certserver.PGP.com. I have enhanced the signing key dialogs, it is now wider and the combo box shows the user ID, full key size information including the DS key size, and the key ID. Many Thanks to Mr. Michael Ray for proposing this change. New in this build is the Key ID column in the recipient dialog. The key ID column is sortable. To sort on the Key ID simply click on the column heading. This should make the selection of recipient keys much easier. I have also added a KeyID column to PGPlog. I must give credit to Lincoln Yeoh and the anonymous poster of a message in alt.security.PGP, for this handy enhancement to PGPlog. The KeyID column modification in this build implements a much cleaner patch to SigEvent.c as suggested by Lincoln Yeoh and later fixed by the original anonymous poster. Many thanks to both Lincoln Yeoh and the anonymous poster. This build also implement the enhancements to the decrypt dialog as suggested by the anonymous poster. This makes the decrypt dialog box more user friendly and informative. 1) It shows the full user ID in the first column, the key size in the second, and the key ID in the third. 2) It displays the key ID of any unknown private keys. The user ID will be reported as "Unknown Private Key" and the size will be reported as "???" 3) It places a key pair icon to the left of the user ID. This will show whether the key is RSA or DH and whether it's active, expired, revoked, or not on your secring file. Unknown keys will display a question mark icon. Please note that for both of the above enhancement the Key ID will be reported correctly in these two instances:- 1) if the key is an RSA key or 2) if the key is DH/DSA and is in your key ring. That is, if the key is a DH/DSA key, and it is not in your keyring the Key ID of the DSA key will be reported instead of the DH key ID. The full text of the usenet posting is available in the file PGPlogmod.txt. If you have agent you may just import this file for easy reading. There was a problem in PGP5.5.3 which caused an un-controled proliferation of key ring backups to occur when the key rings were stored in the root directory. This problem has been addressed in a safe manner in this build. In this build the user may select the number of backup key rings to be maintained by the program. This may be set by the user from the "Number of Key Rings Backups" combo box in the "Files" tab of the PGP preferences dialog. You may chose to maintain from One to Four key rings backup sets, however, I urge all users to set it to the default Four, so that in case of key rings corruption one may always roll back to a previous key rings backup set. So, you assess the risk, and cautiously set this feature accordingly. This build implements the wipe function fix as suggested by Mr. John P. Maassen. It ensures that file is physically flushed to disk before it is closed and deleted. Many thanks to Mr. John P. Maassen for this fix, see PGPlogmod.txt for details about this fix. In this build, if the secret key ring is stored on a diskette, the user is prompted once per program session to insert the floppy into the disk drive, so as to prevent an endless spin of the diskette drive when the user forgets to load it with his key ring diskette. This feature was implemented at the insistence of Patricia Hoskins, thank you Pat. I have always liked to embed my signing key ID and it's fingerprint in the PGP comment block. I never did so, as I have many keys, this meant that for the information to be useful, I should update the comment block whenever I change the signing key, a tedious and error prone process to say the least. So I have addressed this problem in the following way:- In this build is the auto signing key ID and it's fingerprint in the comment block. What this feature does is append on the fly your signing key ID and it's fingerprint to the comment block (please see the signature block of this message below). This should be quite a relief for those who have multiple keys, as you no longer need to manually update your comment block with the new singing key information. Also, it leaves no doubts to you or to the recipient of the message as to what signing key was used (yes some users do not have the Key ID column in PGPlog). The user may toggle this feature via the "Append key Information to comment" check box in the "General" tab of the PGP preferences dialog. In short, the extra information that you provide about your key will assist and encourage the recipient to get your key from the server (if she/he does not have it) in order to authenticate your message. At the request of many users, I have changed the default preferred encryption algorithm to "IDEA". This version of PGP is pre-set to identify itself as:- "PGP Cyber-Knights Templar build 5.5.3ckt". But, if you don't like it:- In this build is the user defined / selectable version string. This feature may be accessed via the "Version String Preference" combo box in the "email" tab of the "PGP Preferences" dialog. I have pre-set the list to 35+ different version strings from various PGP builds, as well as non existent builds at the time of writing. If you do not like any of the pre-set version strings, you may define your own. To do so, enter your own version string in the combo box then click OK. Your custom version string will be stored as the first item in the drop down list. It will remain there until you explicitly change it. You may, in the meantime select any other version string from the list without losing your custom version string. Many thanks to Ghengus Khan, Marty and Nape for suggesting this feature. Please use this feature responsibly. In the old 2.6x PGP you could "double" encrypt a file. That is, first encrypt it with a public key and then encrypt it a second time with conventional encryption to hide the key id. With PGP 5.5.3 once a file has been encrypted with a public key and the file suffix has been changed to .PGP or .ASC you can no longer (from an Explorer context menu) request that it be encrypted again without first removing the .PGP or .ASC file suffix. To remedie this problem, the behavior of the explorer PGP context menu has been changed so that the full compliment of the PGP sub-menu items are shown regarless of the file type. Many thanks to Gogoo for proposing this feature. At the request of Gregory the list of predefined key sizes has been expanded in the key size combo box in the key search dialog. It now includes keysizes up to 16384 bits in one 1k bit increment. The about dialog has now a combo box with many useful links. The links include PGP.com, PGPi.com, the Cyber-Knights Templar home page, Marty's home page, my home page, and the Replay.com ftp site. The build information is now reported in the about dialog. Please note that all my public keys may be found in the signatures directory in the PGP install directory. Please also note that the PGP Outlook Express plugin is not included in this build. Since the source code, as far as I know, has never been released by NAI. For those seeking the Outlook Express plugin, please check in this url for the most recent version:- ftp://ftp.replay.com/pub/replay/pub/PGP/PGP50/3rdparty/outlook/ *************************************** * FAQ - How to install *************************************** If you have an existing version of PGP 5.x.x or PGP6.x on your machine, and you wish to install the C-KT build of PGP, do the followings:- 1) Un-install whatever version of PGP you have (5.x.x or 6.x). 2) Re-boot. 3) Delete these files (if any):-c:\windows\system\PGP*.dll. 4) Install the C-KT build of PGP. 5) Enjoy! Should you have any problems or suggestions, please do not hesitate to contact me. ********************************** I have built this version for my own personal use. I can state that as far as I am aware, there are no back-doors in this build, that the program can generate and use RSA keys up to 2048 bits in length, DH keys up to 4096 bits in length with DSA keys up to 1024 bits in length, and that the integrity of the program has not been compromised by my modifications. Please note, that this is not a "Warezed" version of PGP. And I, the compiler of the source code, hereby declare that I do not own or claim ownership of the binaries so produced. It is being made available "Gratis" to facilitate the process of satisfying the PGP users community that the current commercial release of PGP is still secure and trustworthy. Therefore, it is my fervent hope, that all users of this package observe all applicable laws with regards to copyrights, patents, and other laws that may govern its use. Finally, many thanks to all the users and beta testers who have contributed to this release, your input has been very valuable to us. Best Regards, and Happy Encrypting, Imad R. Faiad PS If you are reading this from CKT.HLP the signature will not verify DISCLAIMER THIS SOFTWARE AND THE ACCOMPANYING FILES ARE DISTRIBUTED "AS IS" AND WITHOUT WARRANTIES WHATSOEVER, EXPRESS OR IMPLIED. SO USE IT AT YOUR OWN RISK. *************************************** * A Message from Greg. *************************************** -----BEGIN PGP SIGNATURE----- Version: PGP 5.5.3ckt http://members.tripod.com/IRFaiad Comment: KeyID: 0x833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBNhu0cLzDFxiDPxutAQG6UAf+Ixej0ozvPPr1i/66Ep3ujnn55Soat46k 5Dqf31ojNnvvaO9t6hnYZZzd4/jIlnBVcjvdKYJbjXIYdUivMzqPx16Cy4dXvn5U EBFxRFa5l9XxUboptGnVHcb6VUTXSCxYmjpWF2DMZAZEaiHsjaYZnnCnIdx87sY+ s7dMa7JdXJMIzJyhFqOLJfacABN266byRf3a+9n6FKj7jYt8hxJbubKaWzEaEYK9 mccn9f5IcdnfxZC/wbYuRJapRrxIwNDDAe4NRLDInNdJsJZ+elq/gyoSMxd1lPJ7 syamuYfT0VWY6kfH1nDLybJeV8EIt87H4RCTWoDgd5MgCkJQmOH8rA== =sVFX -----END PGP SIGNATURE----- -----BEGIN PGP SIGNED MESSAGE----- 98.18.09 When Imad Faiad approached me with the idea of creating a "sanitized" build of PGP5.5.3ckt (one that includes all the user interface enhancements, bug fixes, etc. but without "large key support"), I was immediately taken with the idea. This build will please a lot of people who wanted to take advantage of all the user enhancements, but didn't want the "large key" support. The C-KT build (in either flavor, "sanitized" or "large key capable") is the net result of the efforts of a lot of PGP users who identified various problems or thought of useful enhancements (Lincoln Yeoh, Michael Ray, Patricia Hoskins, John Maassen, and Marty Graybill...just to name a few). PGP5.5.3ckt is more than just a "toy" build that produces very large keys, and has a couple of useful "hacks". PGP5.5.3ckt (sanitized)is what PGP5.5.3 *should have* been when it was released. I have often been asked, "What is the purpose of creating a modified build? What is wrong with the official program released by PGP Inc.?" There is nothing "wrong" with the official program released by PGP Inc. It is a wonderful program, and Phil Zimmerman did a wonderful thing when he developed it. However, when PGP5.5 was released, a few deficiencies in the program became evident (and PGP Inc. didn't appear willing to address them). First among these was the "wipe" bug, not to mention the "rsa-crippled" freeware and the "multiple-backup" problem. It was to address these issues, and others, that this modified build was created. We invite Network Associates to review the changes we have made to the 5.5.3 source code, and consider them for possible inclusion in a future build of PGP. Two people deserve special mention when discussing PGP5.5.3ckt. Those people are Imad Faiad, and Marty Graybill. Marty is the person who originally requested a "modified" build so that it would be able to handle the 8192 bit RSA keys generated by one of the 2.6.3 variations. Imad Faiad made the modification, and compiled the build. Everything just "snow-balled" from there...and now we have two different builds with lots of great features. One can not overstate the contribution of Imad Faiad to PGP5.5.3ckt. He has spent a *lot* of his own time and effort compiling, modifying, and beta-testing these builds. It is fair to say that without Marty Graybill and Imad Faiad, there would be no C-KT build. Enjoy the program, and happy encrypting! Warm Regards, Gregory J Greetan (Cyber-Knights Templar team creator and primary contact) cyber-nyte@usa.net http://netnet.net/~merlin/knights -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: A lie is most convincingly hidden between two truths. Comment: KeyID: 0xA029F345 Comment: Fingerprint: 5D70 0238 0234 E612 AC8F 4743 8F32 CB0D iQEVAwUBNgLobGa5xoqgKfNFAQF7agf/aCq/vY7U4rY83M7IqaJ6Dztl2+sWfxkJ BfQP0gQkuWIqjhGDNwD+TGOrJ3of4eK+1y7SWjjoNyXkKVSEVcHYaemE80HiCV7R AZqa/lWNAQbAYNlvjBgz86aqFPBO+WwUCW3YOBkFyf+8ofW8DkZRfzmN35Rh6ing X5uCqQ0ZSWu+7WnqKcz2gGykU9euFkZ1Jlu8IrH7/MC6vrOCzDLgztbh2g/wggKh 9dduMlX6HxDYtRkyTucMOwJYNzFaGWIvjyMdLj1xNzvn+Fm8KJxHzFVvUOVLsocj P0Pg6o5AqNtHTf1uP9MNUcWI5rfoDRRXe0HL1QUkQn3njKcU6R+Riw== =5IcK -----END PGP SIGNATURE----- *************************************** * A Message From Philip Zimmermann *************************************** -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 There is no advantage for using the keys larger than about 3000 bits. The 128-bit session keys have the same work factor to break as a 3000 bit RSA or DH key. Therefore, the larger keys contribute nothing to security, and, in my opinion, spread superstition and ignorance about cryptography. They also slow everything down and burden the key servers and everyone's keyrings, as well as cause interoperability problems with present and future releases of PGP. Perhaps even more importantly, they also undermine other people's faith in their own keys that are of appropriate size. While it may have been well-intentioned, this massive expansion of key size is a disservice to the PGP community. Also, larger DSA keys don't contribute anything unless the hash grows bigger with it. That requires selecting a good well-designed bigger hash that has been specifically designed to have the full work factor for breaking it. Using two SHA1 hashes in that manner has not been adequately shown to achieve this result. Anyone with a sophisticated understanding of cryptography would not make the keys bigger this way. Experimental code that we put into PGP during its development should not be used. It was protected with conditional compilation flags and should never have been revealed to uninformed users who decide to perform a "public service" by enabling the code and releasing it. This is part of the reason why we ask people not to release code changes on their own, but to send them to us, so that we may incorporate some of them (if they seem like good ideas) into our next product release. That is how PGP enhancements from the user community have always been managed since PGP source code was released in 1991. -Philip Zimmermann -----BEGIN PGP SIGNATURE----- Version: PGP 6.0b16 iQA/AwUBNcIZ0GPLaR3669X8EQIblACePP3jorZ6Y+wjYDRomxMfKgLF2h4AoNmI tjDuzHfhdIqDd6s5BUNIlhBu =3BJC -----END PGP SIGNATURE-----