The 7.x versions of PGP support a "key reconstruction" feature. You have to have the corporate product suite to set this up as it uses a key reconstruction server. The whole scheme is cryptographically secure but does rely on the user to setup a Question/Answer list to recover the key. If your Questions and Answers are not so good (Mother's maiden name, etc.) then you weaken the whole scheme.
--Noah-- On Monday, March 11, 2002, at 09:07 AM, Randall Laura wrote: > 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 :-) >
