Use full disk encryption or nothing.

It will slow down your system a little, but that shouldn't matter unless you're running a shitty cpu.

>>51700684 I don't care if it's "not good enough". I only need to make sure some dumb nigger doesn't access my files when he steals my laptop.

Don't do this OP. This is EFS (https://en.wikipedia.org/wiki/Encrypting_File_System). It's garbage. A placebo at best, which in security means it is worse than useless.

When I was working helpdesk, we would regularly have to recover data encrypted with EFS. It was easy. Never needed a password for it because you can extract the key offline. Yeah. It's goddamn retarded.

If you want to encrypt your shit (a good idea) use a Full Disk Encryption (FDE) solution. For Windows, that's usually Bitlocker nowadays (it used to be shit, but now is decent) or maybe Veracrypt if you're interested in something a bit more cross-platform. Mac users will usually want FileVault 2 and Linux users will want dm-crypt LUKS (cryptsetup).

>>51700704 I fear it will also encrypt the decryption key itself. Where is it stored? I want to encrypt /Users/Me including AppData etc

>>51700792
It's probably good enough as nigger protection desu

>>51700858
if you just want nigger protection, then just put a password on your computer

>>51700794
I think you misunderstand. The decryption key *IS* encrypted. That's the point. The passphrase you type (or the keyfile you provide) is used to derive a key that is then used to decrypt the actual encryption key. This is how you are able to change your password without having to re-encrypt your entire disk.

Generally, there will be multiple key "slots", allowing multiple passphrases to decrypt the disk. When you add a new passphrase, you must provide an existing one to make a copy of the master key, which is then encrypted with the key derived from the new passphrase.

At any point, you can create a backup passphrase using an available key slot. Some FDE products like Bitlocker do this for you automatically, generating a long string of random characters for you to print out and put in a secure location, in case you ever forget your password.

>>51700858
From niggers, sure. But not from the identity thieves that the nigger sells it to. That's actually a pretty big industry.

>>51700792 I know, I don't care. It's not like the FBI is after me. No access from livecd or something is good enogh. 1) nigger steals the laptop 2) nigger tries to read the files 3) nigger gives up after 5 minutes and formats the drive

>>51700898
Oh sorry, I thought
>>51700794
was referring to
>>51700684
not asking about where EFS stores it's key. I was talking about FDE.

>>51700927
Niggers don't reformat drives. They sell the computer. The parts get scrapped and sold, the disks tend to end up on the black market. If you're lucky, you only have personal data and only need to worry about identity thieves. If you're not so lucky, you've got something that leads to business information (saved passwords, perhaps).

But I'm done offering advice. You clearly don't actually want any.

>>51700960
no please dont go, other person here thats interested in this. tell me everything you know

>>51701529
I am still here, brother. Asketh thou a question and I shall bestow upon thine head my glorious knowledge.

Seriously, though. I'm just an amateur crypto nerd, still very much learning myself, but I sort of do this shit for a living, too. What do you want to know?

>>51701772
Does FDE work properly on SSDs?

>>51701917
Yes, with the same caveat as with magnetic spinning disks:

If you *ever* write unencrypted data to a storage device, you must assume that the data can *always* be recovered.

Modern firmware keeps huge lists of hidden blocks in reserve, hidden from the OS. It is expected that many blocks will fail over the lifetime of the device, but the firmware is usually able to recover the data and copy it into a new block. The firmware updates the lists and the OS is unaware that anything happened.

This means that you can never be 100% sure you've actually deleted something. Even if you tell the OS to overwrite every single bit, there will be hidden blocks the OS doesn't know about, and which the disk might be physically unable to alter even if it wanted to.

SSDs take that concept and compound it further. Generally, erasing a cell and writing new data to it is a very, very slow operation. So, instead, the firmware will write to a cell that is already empty instead and update the list so that the OS *thinks* it overwrote the old one. It's more complicated that that and it's been a while since I last looked at that shit, but that's the idea.

All you have to know is that you should only write data that is already encrypted. FDE would do this, but only if you're encrypting the device before using it.

>>51702285
I see. Well the only thing I'll be installing before encryption is Windows so that'll work out well enough.

>>51702422
Some fun details. I forgot to say that there is something known as the ATA Secure Erase that used to be popular. The idea was that you would issue a command directly to the storage device firmware to wipe *everything*, even the hidden shit.

Problem was, it was implementation-specific and vendors suck at writing firmware as a rule. There was a study done that demonstrated not only that they failed to completely wipe the disk, but some didn't do anything at all.

More recently and still related, SSDs are typically "hardware encrypted", which means they have an encryption key stored in the firmware and all data is written encrypted to the disk, transparent to the OS. The idea being that when you want to wipe, you just have to erase the key. Brilliant, right? Well, it would be. But that had the exact same problem; you can't trust the vendors to do it properly.

One of the reasons FDE is such a necessity, especially on Windows, is that file-level encryption is easily defeated by exploiting the behavior of the OS itself. Things like RAM and file "slack" are forensics wet dreams.

Basically, the encryption key gets stored in memory when you use it, right? Obviously. During normal OS use, files are created and modified all the time, especially Windows. If those files don't exactly line up with the file system cluster size, you end up with "slack" at the end. But the block is the smallest unit that can be written to the device, so the OS has to write *something*.

You would think that would mean filling in the slack with zeroes. And you would be wrong. Instead, Windows picks a random address from memory and uses that to fill the slack. Yeah. Seriously. And we're talking about up to 64 kB of slack, here. That's easily enough room for passwords and encryption keys and all sorts of juicy shit.

>>51702662
Sorry, messed up my terminology there a bit and only partially corrected myself. Block = physical sector, cluser = file system allocation unit.

>>51702699
*cluster
Fuck.

Alright, done blogging for now. Got shit to do.