5 ms·

I have always been curious.. is there a better way of accomplishing this?

jszymborski 7y ago
I suspect you can leverage GNU Parallel to get this faster EDIT: Yup, looks like a clever person figured this out https://serverfault.com/questions/46852/doing-an-rm-rf-on-a-massive-directory-tree-takes-hours/107366#107366 https://serverfault.com/questions/46852/doing-an-rm-rf-on-a-...
smacktoward 7y ago
I suppose you could try wiring the receiver up to a USB killer (https://en.wikipedia.org/wiki/USB_Killer https://en.wikipedia.org/wiki/USB_Killer)... Though if you do that, you'll want to be extremely diligent about minding where you step :-D
- rtkwe 7y ago
  You'd need to make sure it actually works, on Macbooks for example the USB ports are all fused so it only kills your USB ports but the rest of the computer is unaffected.
  - fencepost 7y ago
    Not sure I believe that. I've watched Louis Rossmann talking about Apple's fuses.
    - rtkwe 7y ago
      I swear I saw a video of someone doing it but can't find it on a cursory look and it seems the latest macbook has been killed by one. Or at least it turned off, the person videoing didn't try turning it back on to make sure it wasn't just a safety tripping the whole power system.
paxswill 7y ago
Use an encrypted disk, and overwrite the master keys (something like `cryptsetup luksErase <device>` on Linux, probably a combo of `fdesetup list`, `fdesetup remove` and `fdesetup removerecovery` for macOS) and then force a shutdown.
projektfu 7y ago
ATA secure erase. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
- projektfu 7y ago
  More info: http://forum.notebookreview.com/threads/secure-erase-hdds-ssds-sata-nvme-using-hdparm-nvme-cli-on-linux.827525/ http://forum.notebookreview.com/threads/secure-erase-hdds-ss... Also for nvme SSDs.
evil-olive 7y ago
Use full-disk encryption (presumably this is table stakes for anyone with this level of paranoia) using two factors - your passphrase decrypts a keyfile, then the keyfile is used to decrypt the partition. If you destroy the keyfile, then even knowledge of the passphrase won't allow you to decrypt the data. This can be used to defeat a rubber-hose attack [0]. Standard security vs. convenience trade-off applies, of course - if you keep the keyfile on a USB key, then if the USB key fails you lose access to your data. If you keep a backup of the keyfile somewhere else, then access to that backup plus a rubber-hose attack to get your passphrase allows an attacker to decrypt your data. 0: https://xkcd.com/538/ https://xkcd.com/538/
- Miner49er 7y ago
  You still need to do something to prevent a cold-boot attack [0]. 0: https://en.m.wikipedia.org/wiki/Cold_boot_attack https://en.m.wikipedia.org/wiki/Cold_boot_attack
  - mises 7y ago
    Maybe try sdmem: http://manpages.ubuntu.com/manpages/trusty/man1/sdmem.1.html http://manpages.ubuntu.com/manpages/trusty/man1/sdmem.1.html Put it in a bash script with the above luks commands and profit.
- asdfman123 7y ago
  I believe reading that Ross Ulbrict's computer was completely encrypted and only accessible with a passphrase. The minute he logged out or closed his laptop's lide, the information was completely locked down. IIRC, they were able to get his information by an elaborate scheme acted out by plainclothes police where they grabbed his PC while his computer was unlocked. Without looking it up, I think someone bumped into him and one officer took his laptop while another one on the other side grabbed his phone.
  - komali2 7y ago
    Two plain clothes FBI officers followed him into the Glen Park public library. A third, undercover, agent contacted Ross online and asked him to log into the silk road backend to fix something. The plainclothes engaged in a fake lover's tiff right behind Ross' chair, who then turned around to see what the commotion was. When he did so, the male officer pushed the laptop to the female officer, who took it and began extracting evidence. Ross stood up, and then was arrested without resistance. Evidence gathering happened in the library.
tptacek 7y ago
Start by not relying on Full Disk Encryption, which you should absolutely have enabled but should probably, from an OPSEC perspective, pretend does not exist. On modern operating systems you can generally mount and unmount virtual encrypted volumes that are open (ideally) only when you're actually using them to do work with their contents. There used to be a great macOS tool, called Knox, that did this graphically.
- Fnoord 7y ago
  > On modern operating systems you can generally mount and unmount virtual encrypted volumes that are open (ideally) only when you're actually using them to do work with their contents. There used to be a great macOS tool, called Knox, that did this graphically. Cryptomator [1], cross-platform as well. [1] https://cryptomator.org/ https://cryptomator.org/
  - tptacek 7y ago
    The nice thing about Knox is that it just wrapped macOS's built in XTS support. XTS sucks, but you didn't have to think much about what Knox itself was doing. Cryptomator implemented their own FUSE filesystem, and it's a strange collection of SIV, CTR, HMAC, and scrypt. I should like it a lot because I generally like filesystem encryption, but I'd have to actually read it carefully before using it. There's a Cure53 "audit" of it, like for everything else, but to give a sense of how reliable it was, they flagged ECB mode... in the project's implementation of SIV mode.
- btrettel 7y ago
  I run Linux and use full disk encryption, but I also have a few encrypted directories using EncFS. https://en.wikipedia.org/wiki/EncFS https://en.wikipedia.org/wiki/EncFS Right now it's just for sensitive documents (i.e., anything that could be used to steal my identity). I used to also store my passwords in an encrypted directory, but now I've migrated to a password manager (which of course has an encrypted database). If someone steals my computer while it's on and the drive is decrypted, they won't be able to obtain the most sensitive information the vast majority of the time.
oasisbob 7y ago
Haven't tried it, but Google has a "macdestroyer" script in their macops repo which looks interesting: https://github.com/google/macops/tree/master/macdestroyer https://github.com/google/macops/tree/master/macdestroyer
manjana 7y ago
echo 'Hello World' > /dev/sda or mv / /dev/null
- eeZah7Ux 7y ago
  No and no.
  - manjana 7y ago
    Oh yeah, you'll need root ofc., add 'sudo !!' and enter pass. Joke aside: I misunderstood what was asked it appears. Re-reading the original post I'm still unsure what is asked. But to be clear, you shouldn't use these commands if you wish to erase sensitive information, albeit if you use full disk encryption it will not really remove or add any value I suppose. If you want to be sure you could overwrite the disk with random random bits or use a degausser which is properly the most complete/sure method of erasure.
kirykl 7y ago
Rip the drive out and drop it in a strong degausser
davidw 7y ago
Thermite!

I suspect you can leverage GNU Parallel to get this faster EDIT: Yup, looks like a clever person figured this out https://serverfault.com/questions/46852/doing-an-rm-rf-on-a-massive-directory-tree-takes-hours/107366#107366 https://serverfault.com/questions/46852/doing-an-rm-rf-on-a-...

smacktoward 7y ago

I suppose you could try wiring the receiver up to a USB killer (https://en.wikipedia.org/wiki/USB_Killer https://en.wikipedia.org/wiki/USB_Killer)... Though if you do that, you'll want to be extremely diligent about minding where you step :-D

rtkwe 7y ago
You'd need to make sure it actually works, on Macbooks for example the USB ports are all fused so it only kills your USB ports but the rest of the computer is unaffected.
- fencepost 7y ago
  Not sure I believe that. I've watched Louis Rossmann talking about Apple's fuses.
  - rtkwe 7y ago
    I swear I saw a video of someone doing it but can't find it on a cursory look and it seems the latest macbook has been killed by one. Or at least it turned off, the person videoing didn't try turning it back on to make sure it wasn't just a safety tripping the whole power system.

paxswill 7y ago

Use an encrypted disk, and overwrite the master keys (something like `cryptsetup luksErase <device>` on Linux, probably a combo of `fdesetup list`, `fdesetup remove` and `fdesetup removerecovery` for macOS) and then force a shutdown.

projektfu 7y ago

ATA secure erase. https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

projektfu 7y ago
More info: http://forum.notebookreview.com/threads/secure-erase-hdds-ssds-sata-nvme-using-hdparm-nvme-cli-on-linux.827525/ http://forum.notebookreview.com/threads/secure-erase-hdds-ss... Also for nvme SSDs.

evil-olive 7y ago

Use full-disk encryption (presumably this is table stakes for anyone with this level of paranoia) using two factors - your passphrase decrypts a keyfile, then the keyfile is used to decrypt the partition. If you destroy the keyfile, then even knowledge of the passphrase won't allow you to decrypt the data. This can be used to defeat a rubber-hose attack [0]. Standard security vs. convenience trade-off applies, of course - if you keep the keyfile on a USB key, then if the USB key fails you lose access to your data. If you keep a backup of the keyfile somewhere else, then access to that backup plus a rubber-hose attack to get your passphrase allows an attacker to decrypt your data. 0: https://xkcd.com/538/ https://xkcd.com/538/

Miner49er 7y ago
You still need to do something to prevent a cold-boot attack [0]. 0: https://en.m.wikipedia.org/wiki/Cold_boot_attack https://en.m.wikipedia.org/wiki/Cold_boot_attack
- mises 7y ago
  Maybe try sdmem: http://manpages.ubuntu.com/manpages/trusty/man1/sdmem.1.html http://manpages.ubuntu.com/manpages/trusty/man1/sdmem.1.html Put it in a bash script with the above luks commands and profit.
asdfman123 7y ago
I believe reading that Ross Ulbrict's computer was completely encrypted and only accessible with a passphrase. The minute he logged out or closed his laptop's lide, the information was completely locked down. IIRC, they were able to get his information by an elaborate scheme acted out by plainclothes police where they grabbed his PC while his computer was unlocked. Without looking it up, I think someone bumped into him and one officer took his laptop while another one on the other side grabbed his phone.
- komali2 7y ago
  Two plain clothes FBI officers followed him into the Glen Park public library. A third, undercover, agent contacted Ross online and asked him to log into the silk road backend to fix something. The plainclothes engaged in a fake lover's tiff right behind Ross' chair, who then turned around to see what the commotion was. When he did so, the male officer pushed the laptop to the female officer, who took it and began extracting evidence. Ross stood up, and then was arrested without resistance. Evidence gathering happened in the library.

tptacek 7y ago

Start by not relying on Full Disk Encryption, which you should absolutely have enabled but should probably, from an OPSEC perspective, pretend does not exist. On modern operating systems you can generally mount and unmount virtual encrypted volumes that are open (ideally) only when you're actually using them to do work with their contents. There used to be a great macOS tool, called Knox, that did this graphically.

Fnoord 7y ago
> On modern operating systems you can generally mount and unmount virtual encrypted volumes that are open (ideally) only when you're actually using them to do work with their contents. There used to be a great macOS tool, called Knox, that did this graphically. Cryptomator [1], cross-platform as well. [1] https://cryptomator.org/ https://cryptomator.org/
- tptacek 7y ago
  The nice thing about Knox is that it just wrapped macOS's built in XTS support. XTS sucks, but you didn't have to think much about what Knox itself was doing. Cryptomator implemented their own FUSE filesystem, and it's a strange collection of SIV, CTR, HMAC, and scrypt. I should like it a lot because I generally like filesystem encryption, but I'd have to actually read it carefully before using it. There's a Cure53 "audit" of it, like for everything else, but to give a sense of how reliable it was, they flagged ECB mode... in the project's implementation of SIV mode.
btrettel 7y ago
I run Linux and use full disk encryption, but I also have a few encrypted directories using EncFS. https://en.wikipedia.org/wiki/EncFS https://en.wikipedia.org/wiki/EncFS Right now it's just for sensitive documents (i.e., anything that could be used to steal my identity). I used to also store my passwords in an encrypted directory, but now I've migrated to a password manager (which of course has an encrypted database). If someone steals my computer while it's on and the drive is decrypted, they won't be able to obtain the most sensitive information the vast majority of the time.

oasisbob 7y ago

Haven't tried it, but Google has a "macdestroyer" script in their macops repo which looks interesting: https://github.com/google/macops/tree/master/macdestroyer https://github.com/google/macops/tree/master/macdestroyer

manjana 7y ago

echo 'Hello World' > /dev/sda or mv / /dev/null

eeZah7Ux 7y ago
No and no.
- manjana 7y ago
  Oh yeah, you'll need root ofc., add 'sudo !!' and enter pass. Joke aside: I misunderstood what was asked it appears. Re-reading the original post I'm still unsure what is asked. But to be clear, you shouldn't use these commands if you wish to erase sensitive information, albeit if you use full disk encryption it will not really remove or add any value I suppose. If you want to be sure you could overwrite the disk with random random bits or use a degausser which is properly the most complete/sure method of erasure.

kirykl 7y ago

Rip the drive out and drop it in a strong degausser

davidw 7y ago

Thermite!