
-----BEGIN PGP SIGNED MESSAGE----- attila in --with both feet. starting with the premise that a corporation has a fundamental legal right to review all work and communications of any employee, and "acknowledging" that the employer is virtually required to maintain access to documentation to service the regulations of the government, the courts, and the LEAs, the issue is simply HOW? 1. I personally include my own public key in every encrypted message --if I consider the contents important enough to warrant encrypting, not just signing, I consider it important enough not to maintain a plaintext copy. 2. If I consider the contents more than just important -eg: critical, I use one of my unpublished public keys for the file copy. this version, including the encryption software and key library, are kept on a separate ZIP disk from the standard version ZIP disk. as a matter of reference, all temporary space is maintained on the ZIP drive. the major insecurity is the swap space which is maintained on a separate partition which is fully purged at boot time --which is not often enough. I have written secure swappers, or maybe I should say secure except for the transitory time the information may have been swapped out. this can be made further secure by preventing swap for the encryption engine if the system permits it, or even better, use semiconductor memory which leaves no magnetic media residuals to be analyzed 500 levels down by the Feds. From a mechanical standpoint there is no difference when you apply the same methods to the corporate environment. Again, the issue is HOW it is implemented. 1. if a corporate entity uses a single private-public keypair for each and every employee, that is their own stupidity as this is insecure, both internal and external. Too many hands on the private key. 2. ideally, each employee should be given a separate corporate public key. at the very least the key can represent a department or work group. 3. using the scenario in 2, specific projects can use a second corporate key which permits group leader management control. Therefore: Is this GAK? unfortunately, yes. By tolerating the use of unfortunately, yes. corporate GAK are we setting ourselves up to accept personal GAK? why? individuals will be desensitized to defending the absolute importance of maintaining our Constitutional rights, what few the Supreme Court has not yet denigrated. can we avoid this result? YES! GAK for businesses is a slam dunk, eg: if business has it, LEA, etc. can get it. desensitization can be minimized by pressuring professional associations to keep the issue of _personal_ privacy on the hot burner; this is the only issue. our mission must be to keep the fire out front so Americans will not stand for the total loss of privacy, etc. that F[reeh,uck] is hawking to our government; F[reeh,uck] sings the siren song of anti-terrorism, anti-anarchy, and all that good stuff government wants to suppress in violation of the Constitution. if the general public is fully aware of the implication, there is a chance to lead the rabble with the the chant: hell no, we wont dump our crypto! Now that the NYTimes has seen the light and is joining the battle against the forces of encryption denial, the mainstream press may make some effort in the cause, but we must keep the pressure on high. CDT, EPIC, and the rest of them are funded by business, big business, all of whom have a vested interest in selling product. they are the employers of the inside-the-beltway whores ...pardon me: lobbycritters; and they will compromise our individual rights in the corporate interests of the almighty dollar; in fact, corporate managers and beancounters will violate the privacy of their employees faster than the US spooks, both on and off the job --they have little if any concept of personal Constitutional privacy rights corporate officers are clueless on personal privacy. we face a two edged sword. if we encourage the expanded use of encryption in business, it will spread much more readily to the private sector --knowing full well the corporate users will be subjected to GAK. If business units are smart, they will implement the multi-target encryption and fight like hell against what F[reeh,uck] really wants: on-the-fly, real-time trapdoor cleartext --just like clipper. If F[reeh,uck] gets what he wants, why should he ask a court for approval to decrypt when he can already glean the information in the same way POTS taps are real time. if we rant and rave against the multi-public key encryption system, we risk facing the far more Draconian demands of F[reeh,uck]. The multi-public key system has been in use since the first time the ability to use multi-keys for multi-recipients was included. there is nothing we can do in the courts to prevent corporations processing encrypted mail through servers for verification, or even content scanning. business has this right --unfortunately, the government can compel the business to exercise this "right" and therefore government potentially does have real-time access. THE FOCUS: All efforts need to be directed to prevent the inclusion of master keys in hardware and/or software and the mandating of universal usage of the government system. there is little difference in what F[reeh,uck] is proposing and Clipper --and the same arguments can challenge F[reeh,uck] and friends. Let's not waste time hashing and rehashing business practices we have long since been forced to accept; and stay away from politics: FOCUS on our Constitutional rights. death is inevitable --an action we all face; some things are worth dying early defending --my personal privacy rights and the sanctity of my intellectual processes or whatever I wish to cogitate or regurgitate is one of them. For the masses: '54-40 OR FIGHT' or any number of us will die martyrs; STAND UP AND BE COUNTED; dont be government wimps, snitches, and shills like Hallam-Baker. attila on the way out ______________________________________________________________________ "attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0 -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: latin1 Comment: No safety this side of the grave. Never was; never will be iQCVAwUBNDhTsb04kQrCC2kFAQGD0wP+JJ6GvszXDmBJcyTaGy9nbXSQb5y0kKUW NgZZHQDJlsVGdU4zPWl3HX7QClpjCBWEucWHiZa9BlyyMA55ngAYJiLv6+EzGZCi AuFYjJBbHin8krgauM/iy4Pj1aXZcIMorWEUYJsfRoHEWCtwPikrwCNCBqzj/N+6 3CpuA31WeeQ= =Cg9I -----END PGP SIGNATURE-----