PGP Corporate Desktop does support key recovery. However, you can not recover keys that have not been created with the reconstruction option. Essentially that entails an Administrator creating a PGP install with the PGP Admin tool that allows/forces the user to utilize the reconstruction options at the time the key is generated. It also requires the use of a keyserver that will accept reconstruction data.
If you have a support contract with NAI they should provide you with a replacement copy of the full version. Otherwise the trial version is available on their website and there are freeware versions available here http://www.pgpi.org/products/pgp/versions/freeware/ If you need help setting all of this up please let me know. Vicky ----- Original Message ----- From: "Randall Laura" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 11, 2002 12:07 PM Subject: PGP Desktop Software > Does anyone have a copy of the PGP Corporate Desktop file encryption > software. It is no longer available for download at pgp.com due to > product maintenance. Also, does anyone know if PGP Corporate Desktop > supports Key Recovery of lost keys? > > Thanks, > Laura > > Peter Lee wrote: > > > > ----- Original Message ----- > > From: Mike Shaw <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, March 07, 2002 06:25 > > Subject: VLAN as a DMZ > > > > > There are definitely textbook reasons (secondary compromize issues, etc), > > > but does anyone know of a specific technical reason why using a VLAN for a > > > DMZ segment is a bad idea (cisco 5500 switch)? > > > > > > > Provided it's properly designed so there is no way for machines in the DMZ > > VLAN to communicate with the switch (to change the VLAN memberships - Telnet > > is not your only concern here, remember SNMP), AND that the switch (L3/RSM) > > does not route between the DMZ VLAN and the other VLAN's, AND the only > > connection between the DMZ VLAN and the internal network is via a filtering > > device like a firewall, then I can't see that it's much different from > > having the DMZ on a physically separate backplane. > > > > However, from an operational perspective, it's harder to manage. > > Personally, I'd never do it, I think the risk of someone accidentally > > cross-patching the DMZ and other VLAN's, or plugging a machine into the > > wrong VLAN, is too high. I do have at least one gov customer who does it. > > > > > The VLAN would have no telnet interface living on it, and no level 3 > > > switching/routing going to/from it. It'd be just an isolated segment. > > The > > > only thing I could think of would be that someone could spoof the > > > frame-tagging or something. > > > > > > > This should not be an issue, as you should only see tagged frames on trunked > > links. Certainly all the VLAN networks I've ever worked with have worked in > > this way. Even if a malicious entity can inject tagged frames into the > > (untagged) segment, unless the receiving device is expecting tagged frames > > then the packets are basically dropped, because the Ethertype field is not > > IP, ARP, ARP reply or something else the protocol stack was expecting. > > > > On the other hand, my very flimsy understanding of Cisco VLAN's is that the > > switches can be in some sort of "auto" mode, where if they see a tagged > > frame they'll automatically process it as a trunked link. This could be an > > issue for you. > > > > The other thing which could be an issue is CDP. You'll want to turn it off > > on the DMZ VLAN, otherwise a malicious entity could capture information of > > use in mounting further attacks. > > > > Unless you have really pressing reasons (like backplane bandwidth or > > rackspace) for doing so, from a risk management perspective I think a > > physically separate DMZ backplane makes a lot of sense :-)
