Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
at Monday, February 10, 2003 3:20 AM, Jim Choate [EMAIL PROTECTED] was seen to say: On Sun, 9 Feb 2003, Sunder wrote: The OS doesn't boot until you type in your passphrase, plug in your USB fob, etc. and allow it to read the key. Like, Duh! You know, you really ought to stop smoking crack. Spin doctor bullshit, you're not addressing the issue which is the mounting of an encrypted partition -before- the OS loads (eg lilo, which by the way doesn't really 'mount' a partition, encrypted or otherwise - it just follows a vector to a boot image that gets dumped into ram and the cpu gets a vector to execute it - one would hope it was the -intended- OS or fs de-encryption algorithm). What does that do? Nothing (unless you're the attacker). indeed. it usually boots a kernel image with whatever modules are required to get the main system up and running; There are two and only two general applications for such an approach. A standard workstation which isn't used unless there is a warm body handy. The other being a server which one doesn't want to -reboot- without human intervention. Both imply that the physical site is -secure-, that is the weakness to all the current software solutions along this line. The solution is only applicable to cold or moderately tamper-proofed systems, to prevent analysis of such systems if confiscated. It can only become a serious component in an overall scheme, but this is universally true - there is no magic shield you can fit to *anything* to solve all ills; this will add protection against the specified attacks and in fact already exists for windows (drivecrypt pluspack) - it is just non-windoze platforms that lack a product in this area.
Re: Putting the NSA Data Overwrite Standard Legend to Death...(fwd)
No shit Sherlock, that's the whole point! The OS doesn't boot until you type in your passphrase, plug in your USB fob, etc. and allow it to read the key. Like, Duh! You know, you really ought to stop smoking crack. --Kaos-Keraunos-Kybernetos--- + ^ + :NSA got $20Bil/year |Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ --*--:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. [EMAIL PROTECTED] http://www.sunder.net On Sun, 9 Feb 2003, Jim Choate wrote: On Sat, 8 Feb 2003, Sunder wrote: At least with a unixish OS you can mount your crypto file systems up at boot time before the OS really starts up (before the system goes to multi-user mode for example (at the end of /etc/rc1.d and before the rc2.d init starts.) Which is a blind path since those files -must- be unencrypted and if they do mount the disk they have to have access to the key to unencrypt the fs hence you're in the same boat as with Winblows.
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
at Monday, February 10, 2003 3:09 AM, Jim Choate [EMAIL PROTECTED] was seen to say: On Mon, 10 Feb 2003, Dave Howe wrote: no, lilo is. if you you can mount a pgpdisk (say) without software, then you are obviously much more talented than I am :) Bullshit. lilo isn't doing -anything- at that point without somebody or something (eg dongle) being present that has the -plaintext- key. Without the key the disk isn't doing anything. So no, lilo isn't mounting the partition. It -is- a tool to do the mount. I don't understand why this concept is so difficult for you - software *must* perform the mount; there is absolutely no way you could personally inspect every byte from the disk and pass decrypted data to the os at line speed yourself. lilo is the actor here. If you gave a program spec to a programmer and said write this you wouldn't be able to claim you wrote the code yourself, no matter how good or essential the program spec was. As to mounting the disk without software, not a problem it could be done all in hardware. Though you'd still need the passphrase/dongle. you couldn't *mount* a disk in hardware; you *could* decrypt on-the-fly and make the physical disk look like a unencrypted one, but you would still need non-crypto software to mount it. for virtual drives, the real question is at what point in the boot process you can mount a drive - if it is not until the os is fully functional, then you are unable to protect the os itself. if the bootstrap process can mount the drive before the os is functional, then you *can* protect the os. No you can't. If the drive is mounted before the OS is loaded you can put the system into a DMA state and read the disk (screw the OS) since it's contents are now in plaintext. no, you can't. data from the hardware is *still* encrypted; only the output of the driver is decrypted, and a machine no longer running bootstrap or os is also incapable of decryption. you *could*, if good enough, place the processor in a halt state and use DMA to modify the code to reveal the plaintext, but it would be a major pain to do so and would require both physical access to the machine *while powered up and without triggering any anti-tamper switches* after the password has been supplied. This is actually a weakness in firmware cryptodrives (as I have seen advertised recently) - once the drive is unlocked it can usually be swapped over to another machine and the plaintext read. You can also prevent the default OS from being loaded as well. Indeed so, yes. however, usually that decision has to be made before the password would be entered - so making more awkward. you *could* finangle the bootstrap though; there must *always* be part of the code outside the crypto envelope (but of course this can be removable media such as the usb drive mentioned, and stored securely when not in use) Clue: If you own the hardware, you own the software. indeed so. however, if that applied to machines not already running, the police wouldn't be so upset when they find encrypted files on seized hardware.
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
On Mon, 10 Feb 2003, Dave Howe wrote: no, lilo is. if you you can mount a pgpdisk (say) without software, then you are obviously much more talented than I am :) Bullshit. lilo isn't doing -anything- at that point without somebody or something (eg dongle) being present that has the -plaintext- key. Without the key the disk isn't doing anything. So no, lilo isn't mounting the partition. It -is- a tool to do the mount. Subtle but important distinction. As to mounting the disk without software, not a problem it could be done all in hardware. Though you'd still need the passphrase/dongle. for virtual drives, the real question is at what point in the boot process you can mount a drive - if it is not until the os is fully functional, then you are unable to protect the os itself. if the bootstrap process can mount the drive before the os is functional, then you *can* protect the os. No you can't. If the drive is mounted before the OS is loaded you can put the system into a DMA state and read the disk (screw the OS) since it's contents are now in plaintext. You can also prevent the default OS from being loaded as well. Clue: If you own the hardware, you own the software. -- We are all interested in the future for that is where you and I are going to spend the rest of our lives. Criswell, Plan 9 from Outer Space [EMAIL PROTECTED][EMAIL PROTECTED] www.ssz.com www.open-forge.org
Re: Putting the NSA Data Overwrite Standard Legend to Death...(fwd)
On Sun, 9 Feb 2003, Jim Choate wrote: On Sun, 9 Feb 2003, Sunder wrote: No shit Sherlock, that's the whole point! Actually it's not, the point is to stop the attacker in their tracks. Sigh, I don't know why I'm bothering to write anything your clueless way... he we go. We're guaranteed you'll miss every point here, but what the fuck - I'm feeling masochistic today and so I'll visit Choate'. Yes, that is the meta-goal here. Encrypting a disk prevents the attacker from just stealing the disk and using another OS to access the data. You still need to solve the issue of the OS itself accessing the data. But you want to encrypt things such as the swap, temp files, etc because they can leak data and possibly your key. Other vectors of attack come into play after the OS has booted fully and include such things as vulnerabilities in the OS itself, applications, software key grabbers, etc. We won't address those here. The OS doesn't boot until you type in your passphrase, plug in your USB fob, etc. and allow it to read the key. Like, Duh! You know, you really ought to stop smoking crack. Spin doctor bullshit, you're not addressing the issue which is the mounting of an encrypted partition -before- the OS loads (eg lilo, which by the way doesn't really 'mount' a partition, encrypted or otherwise - it just follows a vector to a boot image that gets dumped into ram and the cpu gets a vector to execute it - one would hope it was the -intended- OS or fs de-encryption algorithm). What does that do? Nothing (unless you're the attacker). A Spin Doc is a marketting guy who puts a spin on a story, I'm unsure what you mean here. Perhaps Ad Homeneim would be better suited - save that there is a long history between you and reality. :) LILO lives in either the MBR or the 1st sector of the Linux boot partition. (The same applies to GRUB and other boot loaders for other OS's) All it needs to do is load the kernel plus the initrd image (ram disk containing kernel modules for various drivers such as the disk.) At this point you can do one of several things: You can compile in a small blowfish/SHA implementation into LILO and have LILO ask you for your passphrase if you want the kernel to live in the encrypted disk. In this case you'll need some mechanism to pass the key to the kernel so when it kicks in the encrypted disk driver, it'll be able to mount /, etc. Otherwise /boot can be naked so long as you diff it against a CD or another known pristine source. Any changes there and you've got a dead canary. :) If /boot is naked, and that's fine too so long as you take care when your system mysteriously reboots. At this point, the kernel boots up, the initrd image is available to it so it can load its modules, one of which can be the encrypting block driver can load. When it does, it can ask for the passphrase for each volume to mount when mount is called, etc. You may have some fun with having to tell the kernel what device / lives on, and so long as the encrypted block device driver is used, it'll mount it from there. Same with swap and other partitions. If you wanna do a USB fob or other device, you'll need to have the driver for that fob (and anything else it'll need) loaded before the encrypting block driver, and of course the underlying IDE/SCSI drivers need to be loaded in the kernel before it too. There are two and only two general applications for such an approach. A standard workstation which isn't used unless there is a warm body handy. The other being a server which one doesn't want to -reboot- without human intervention. Both imply that the physical site is -secure-, that is the weakness to all the current software solutions along this line. No shit, if you're hackable at the physical layer, all bets are already off - you can consider yourself owned - it's just a matter of time. And physical restraints do nothing other than delay an attacker. If you're hackable - say in a way that will give your attacker remote root access, it's actually worse than the attacker having physical access because your OS is running, it's encrypted partitions are accessible and mounted - and if your attacker can install a kernel module, you're douily fucked as you won't be able to detect their presence. For physical access, the best you can do is attempt to detect the event, send out warnings, and log the event, wipe RAM and halt the machine; then it doesn't matter, the attacker has nothing more than a pile of hardware with some random numbers on its spindles. Useless without the key worth whatever ebay will pay for it. This is why a keyboard is not a good way to enter a passphrase - it can be removed from the PC and modified, or taken apart without disconnecting it and a capture device added - just turn it upside down, unscrew, solder, screw and done. The best you can do with a workstation is to have it on all the time and have something watching it for reboots, outages,
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
Jim Choate wrote: Yes, it can mount the partition. That isn't the problem. The problem is that for lilo to do this it has to have access to the key in plaintext. That makes the entire exercise moot. not if you have to type it every time. if you take that as criteria, then *all* encryption is moot, as I can't think of any you don't have to supply a key or passphrase for. you could also have lilo look at a dongle (a usb drive, say) for its key.
Re: Putting the NSA Data Overwrite Standard Legend to Death...(fwd)
On Sat, 8 Feb 2003, Sunder wrote: In real life this will not work as most Windoze hard disk encryption schemes can't encrypt the OS disk - and this is where the temp/cache stuff goes. These can have more than enough info to reveal what's on your crypto disk (ie. shortcuts to url's you've recently visited, recently opened documents, etc...) At least with a unixish OS you can mount your crypto file systems up at boot time before the OS really starts up (before the system goes to multi-user mode for example (at the end of /etc/rc1.d and before the rc2.d init starts.) Which is a blind path since those files -must- be unencrypted and if they do mount the disk they have to have access to the key to unencrypt the fs hence you're in the same boat as with Winblows. -- We are all interested in the future for that is where you and I are going to spend the rest of our lives. Criswell, Plan 9 from Outer Space [EMAIL PROTECTED][EMAIL PROTECTED] www.ssz.com www.open-forge.org
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
Jim Choate wrote: On Sat, 8 Feb 2003, Sunder wrote: In real life this will not work as most Windoze hard disk encryption schemes can't encrypt the OS disk - and this is where the temp/cache stuff goes. Not always - certainly, windows cache goes to a partition that must be available at windows startup - but webbrowser cache can happily live on an encrypted disk (I have done this many times) Further, there is always the Drivecrypt pluspack which mounts an encrypted volume before windoze starts, and hands over to windoze as it comes up (I believe the same mechanism is used as for doublespaced drives, but I can't be sure; drivecrypt is closed source, hence I refuse to use it) At least with a unixish OS you can mount your crypto file systems up at boot time before the OS really starts up (before the system goes to multi-user mode for example (at the end of /etc/rc1.d and before the rc2.d init starts.) Which is a blind path since those files -must- be unencrypted and if they do mount the disk they have to have access to the key to unencrypt the fs hence you're in the same boat as with Winblows. At least in theory a lilo boot could mount an encrypted partition while still in the initrd stage; as crypto support is moved into the kernel, I expect to see this become an available option.
Re: Putting the NSA Data Overwrite Standard Legend to Death...(fwd)
On Sun, 9 Feb 2003, Dave Howe wrote: Jim Choate wrote: Yes, it can mount the partition. That isn't the problem. The problem is that for lilo to do this it has to have access to the key in plaintext. That makes the entire exercise moot. not if you have to type it every time. Then I'd say lilo isn't mounting it, you are. But you get the gist, either the key is there in plaintext or somebody who knows it is. That is a -very- limited application area for computers and encryption. if you take that as criteria, then *all* encryption is moot, as I can't think of any you don't have to supply a key or passphrase for. Not at all, it simply means that encryption is not the solution for -stand alone- applications (at least not at the state of encryption and hardware today). In my mind the utility of encryption on a machine is questionable unless that machine can reboot and recover -without intervention and without needing a plaintext key-. Only when that state can be achieved will encryption offer the sort of security many of us are looking for. One of the extensions that I'm looking at in Plan 9 is a mechanism to use the distributed process and name space as a mechanism to do something about this. It may be possible to get a server to boot an encrypted partition without ever passing the actual key (Plan 9 uses a token ala kerberos - but it's not kerberos). you could also have lilo look at a dongle (a usb drive, say) for its key. Same problem, the key has to be on the dongle in the clear. Several years ago the Austin Cypherpunks ran a mixmaster remailer for several months and we used a floppy to do this sort of stuff. If you have the floppy you have the system. -- We are all interested in the future for that is where you and I are going to spend the rest of our lives. Criswell, Plan 9 from Outer Space [EMAIL PROTECTED][EMAIL PROTECTED] www.ssz.com www.open-forge.org
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
Jim Choate wrote: On Sun, 9 Feb 2003, Dave Howe wrote: Jim Choate wrote: Yes, it can mount the partition. That isn't the problem. The problem is that for lilo to do this it has to have access to the key in plaintext. That makes the entire exercise moot. not if you have to type it every time. Then I'd say lilo isn't mounting it, you are. no, lilo is. if you you can mount a pgpdisk (say) without software, then you are obviously much more talented than I am :) for virtual drives, the real question is at what point in the boot process you can mount a drive - if it is not until the os is fully functional, then you are unable to protect the os itself. if the bootstrap process can mount the drive before the os is functional, then you *can* protect the os. Win9x uses dos as its bootstrap (and drivespace gives a good example of a virtual drive system that can hand over to a 32bit driver as the os starts). lilo *could* kick a virtual drive into existence during the kernel boot, given such a driver and some patches to both kernel and lilo itself. that it would need a password from somewhere during this process is both obvious and not a major issue.
Re: Putting the NSA Data Overwrite Standard Legend to Death...(fwd)
In real life this will not work as most Windoze hard disk encryption schemes can't encrypt the OS disk - and this is where the temp/cache stuff goes. You can change both where your browser caches stuff off the web and the temp folder so that's ok, but this doesn't work well because temp has to be available when you login, but since you haven't yet logged in, you couldn't have unlocked your crypto drive. Even more so, the registry, your pagefile, and if you've got a notebook - hybernation file, all go to naked disk. These can have more than enough info to reveal what's on your crypto disk (ie. shortcuts to url's you've recently visited, recently opened documents, etc...) At least with a unixish OS you can mount your crypto file systems up at boot time before the OS really starts up (before the system goes to multi-user mode for example (at the end of /etc/rc1.d and before the rc2.d init starts.) So far I've yet to see something that encrypts an entire hard drive - OS and all - except unless you're willing to go with something like VMWare or Bochs and keep the OS that you do your work from on an encrypted volume. You can probably hack some SAN-like thing together and have the SAN box do the crypto - so long as the disk provided by the SAN looks like any other IDE or SCSI disk, it'll encrypt everything - but such things are insanely expensive. It may be possible to do this via USB2/Firewire if your BIOS supports it, and you have the ability to build a SAN that talks USB2/firewire... but haven't seen this on the market... likely a small SBC with the proper ports and drivers to make itself look like a disk are the way to go. Think Archos Multimedia Jukebox and iPod with rewritten OS + a way to enter the key not into your PC but in the jukebox. Or if you've got the coding skills and brass cajones, write your own hard disk driver for windblows that can query either a USB fob or keyboard or whatever for the passphrase during OS bootup. Even so, if there are any vulnerable services - i.e. autorun enabled CD, drive shares, web server with security hole, all the crypto in the world won't keep your data private. Add to that any hardware key catchers, mini-camera in the ceiling watching your keystrokes, etc --Kaos-Keraunos-Kybernetos--- + ^ + :NSA got $20Bil/year |Passwords are like underwear. You don't /|\ \|/ :and didn't stop 9-11|share them, you don't hang them on your/\|/\ --*--:Instead of rewarding|monitor, or under your keyboard, you \/|\/ /|\ :their failures, we |don't email them, or put them on a web \|/ + v + :should get refunds! |site, and you must change them very often. [EMAIL PROTECTED] http://www.sunder.net On Thu, 6 Feb 2003, Tyler Durden wrote: I've got a question... Will this work for -everything- that could go on a drive? (In other words, if I set up an encrypted disk, will web caches, cookies, and all of the other 'trivial' junk be encrypted without really slowing down the PC?) The reason I ask is that's it's very easy to imagine that, say, FedGroup X wants to take out some outspoken or otherwise questionable person by secretly introducing some kiddie porn or whatnot onto the drive. 15 minutes later they burst through the door and grab the PC. If I buy PGP off the shelf, will it make the ENTIRE drive encrypted? (And will I wait half an hour for Hard Drinkin' Lincoln to download?)
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
At 09:34 AM 02/06/2003 -0500, Tyler Durden wrote: I've got a question... If you actually care about the NSA or KGB doing a low-level magnetic scan to recover data from your disk drives, you need to be using an encrypted file system, period, no questions. OK...so I don't know a LOT about how PCs work, so here's a dumb question. Depends on the operating system you're running and the file system encryption program you're running and the options you've picked when running them. (There are no dumb questions, just questions leading to overly-general answers...) Will this work for -everything- that could go on a drive? (In other words, if I set up an encrypted disk, will web caches, cookies, and all of the other 'trivial' junk be encrypted without really slowing down the PC?) As far as slowing down the PC goes, it depends a lot on how fast your CPU is, how much memory you've got, how fast your disks are, how overloaded your machine is already, etc. On newer machines, this isn't too likely to be a problem, and older machines can be fixed by not running Windows If you're a gamer, you're more likely to worry about the performance, but more likely to have a fast enough CPU... The usual things you need to protect are - Files and filenames and directories - almost everything does this - Swap Space - this one's often hardest to get right, depending on the operating system. - Temp files and log files that let you decide where to put them - Temp files and log files that don't document where to put them (Windows is full of these) - File Systems / Partitions / etc. - many of the programs let you create additional virtual disks (e.g. D:, E:, F: on Windows, cute icons on Macs), but not all the programs can do C: or Unix / root drives. Creating additional virtual disks doesn't usually give you encrypted swap space or encrypted undocumented temp directories, unless you've got an operating system that lets you specify where the swap goes and only enable it after turning on the encrypted drive. If you want to know what PGPdisk does off the shelf, with the current incarnations of PGP.com and PGPdisk, I'd say ask Jon Callas. The reason I ask is that's it's very easy to imagine that, say, FedGroup X wants to take out some outspoken or otherwise questionable person by secretly introducing some kiddie porn or whatnot onto the drive. 15 minutes later they burst through the door and grab the PC. If they can secretly introduce things onto your disk, you've got a raft of other problems - can they secretly introduce a password stealer? On the other hand, they could email you some thoughtcrime and then bust in, or stego it into legitimate things you're downloading (Wow, Yahoo Maps seems sss.lll..www Today!) (This new freebie game 'Trojan Horse' is fun, but the download's pretty big!)
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
If you actually care about the NSA or KGB doing a low-level magnetic scan to recover data from your disk drives, you need to be using an encrypted file system, period, no questions. There are occasional articles that pop up on the net talking about somebody's improved capability for data recovery. If you're part of a US government agency with NSA or DoD rules, that isn't necessarily required, or approved as adequate, but that's strictly an issue of their flexibility. On the other hand, if your threat model includes the Mafia, you might want to get some steel kneecaps pre-installed. It's been a long time since I've read any official regulations on this topic, and at the time they were mostly for declassifying equipment that formerly held classified data: - either use physical destruction, or - use an officially NSA-approved Big Magnet, or - use software that's been approved by your security officer for your operating environment and remember that you need to wipe memory as well. My reaction to letting any NSA-approved Big Magnets near any of *my* computers was absolutely no way - keep them outside our TEMPEST shield so they don't bother my working disk drives.:-) And I was never convinced we'd find officially-approved disk-wiping software that would actually run on Unix as opposed to VMS and wouldn't require immense reams of paperwork to get permission for. But our building had a machine shop in the basement, so when the sysadmin after me decommissioned the VAX, she got to help sandblast the disk drives. I don't know what they did about RAM, if anything. Most sysadmins in those days had wall decorations made from the disk drive platters with nice stripes on them left by the head crash. Hers was sandblasted smooth metal :-) Our standard on ATT 3B2 computers was to wipe memory 3 times, and there was a special program that would wipe half the RAM, relocate itself into that half, and then wipe the other half, using first 0s, then 1s, then a (fixed? random?) bit pattern.
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
at Thursday, February 06, 2003 2:34 PM, Tyler Durden [EMAIL PROTECTED] was seen to say: I've got a question... If you actually care about the NSA or KGB doing a low-level magnetic scan to recover data from your disk drives, you need to be using an encrypted file system, period, no questions. OK...so I don't know a LOT about how PCs work, so here's a dumb question. Will this work for -everything- that could go on a drive? (In other words, if I set up an encrypted disk, will web caches, cookies, and all of the other 'trivial' junk be encrypted without really slowing down the PC?) Provided the drive is mounted, yes. and there is no without slowing down the pc - obviously it *will* cost CPU time (you are doing crypto on each virtual disk sector on the fly), but it shouldn't impact on bandwidth unless you have a really slow pc. Virtual drives occupy a drive letter like a normal drive. most (including pgpdisk) have to be mounted while windows is already running - ie, there is nothing at that disk letter until you run a program and type a password. Some (like DriveCrypt Pluspack) allow the boot volume to be a virtual volume and be mounted *before* windows starts running. Easiest way to find out what you can and can't do is download Scramdisk or E4M, and play :)
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
I've got a question... If you actually care about the NSA or KGB doing a low-level magnetic scan to recover data from your disk drives, you need to be using an encrypted file system, period, no questions. OK...so I don't know a LOT about how PCs work, so here's a dumb question. Will this work for -everything- that could go on a drive? (In other words, if I set up an encrypted disk, will web caches, cookies, and all of the other 'trivial' junk be encrypted without really slowing down the PC?) The reason I ask is that's it's very easy to imagine that, say, FedGroup X wants to take out some outspoken or otherwise questionable person by secretly introducing some kiddie porn or whatnot onto the drive. 15 minutes later they burst through the door and grab the PC. If I buy PGP off the shelf, will it make the ENTIRE drive encrypted? (And will I wait half an hour for Hard Drinkin' Lincoln to download?) -TD _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail
Re: Putting the NSA Data Overwrite Standard Legend to Death...(fwd)
On Thu, 6 Feb 2003, Tyler Durden wrote: Will this work for -everything- that could go on a drive? (In other words, if I set up an encrypted disk, will web caches, cookies, and all of the other 'trivial' junk be encrypted without really slowing down the PC?) Depends on how well you build the encryptor. If you put a box between the board and the disk which has lots of static ram you can pretty much make speed a non-issue. The reason I ask is that's it's very easy to imagine that, say, FedGroup X wants to take out some outspoken or otherwise questionable person by secretly introducing some kiddie porn or whatnot onto the drive. 15 minutes later they burst through the door and grab the PC. If I buy PGP off the shelf, will it make the ENTIRE drive encrypted? (And will I wait half an hour for Hard Drinkin' Lincoln to download?) PGP is file based. It would be hard to push data onto a drive, but it's pretty easy to eavesdrop. Usuall targets do stupid things, much easier to take advantage of that. A web search on encrypted disk will get you some software based tools. Patience, persitsence, truth, Dr. mike
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
Thomas Shaddack [EMAIL PROTECTED] writes: Second, where did the number 7 really come from? From the OSI 7-layer model, which took it from the fact that the number 7 is sacred to a certain tribe in Borneo (see The Elements of Networking Style, by Mike Padlipsky). Peter.
Re: Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
From the OSI 7-layer model, which took it from the fact that the number 7 is It's simpler than that. Russians wanted 6, americans 8. = end (of original message) Y-a*h*o-o (yes, they scan for this) spam follows: Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Putting the NSA Data Overwrite Standard Legend to Death... (fwd)
-- Forwarded message -- Date: Tue, 04 Feb 2003 10:57:09 -0600 Subject: Putting the NSA Data Overwrite Standard Legend to Death... From: Jonathan G. Lampe [EMAIL PROTECTED] To: [EMAIL PROTECTED] OK, I'm sure this one will start a flame war, but...I work for a vendor whose products overwrite files when deleting them as a way of protecting old data. Lately several customers have been asking for NSA or DoD standard overwrites, usually with a value of 3, 7 or 9. (Our response to the feature was to more or less let the owner of the product pick the number of overwrites; the obvious tradeoff is morewrites=slowerdisk.) Anyway, while researching how we wanted to document recommended values for the overwrite feature, I looked into the DoD and NSA standards. I was not surprised to see that a DoD standard DOES exist: Government name: DoD 5220.22-M A nice summary: http://www.zdelete.com/dod.htm (not my product) Some original documents: http://www.dss.mil/isec/nispom.htm Long story short: 1 overwrite = CLEAR, 3 overwrites = SANITIZED (non-removable rigid disk) I was surprised, however, to learn that a NSA standard DOES NOT exist. I did the usual Google searches and came up with nothing but various sites and postings claiming the standard was anything from 5 to 20 overwrites. Then I called the NSA (1-800-688-6115 - http://www.nsa.gov/isso). The first person I chatted with passed on the question, but the second answered the question in no uncertain terms - NSA is aware of DoD 5220.22-M and DOES NOT have a separate recommendation. So...could this finally be the end of IT employees casually tossing around the NSA overwrite standard - or is there something I'm missing? Second, where did the number 7 really come from? (It seems to be the leading recommendation out there right now for number of overwrites and is frequently attributed to the NSA.) - Jonathan Lampe, GCIA, GSNA - [EMAIL PROTECTED]
