Advice for buying a private laptop

General Tor and Anonymity Talk
1

I don’t know if there is much advice to give, but I wanted advice about what is a good new laptop from a privacy, security, paranoia perspective.

I probably won’t run Qubes on it, but will run Linux. I want it to be free as possible. So it would be great if it didn’t need any blobs to run the hardware. That being said, I don’t want to buy something that is like five years old or anything. I need standard good performance, but I don’t need good graphics or anything.

Between Intel and AMD is one preferable over the other?

Any other concerns I should think about?

2

http://kkkkkkkkkk63ava6.onion/wiki/Computer_Security_Education#Using_Open-source_Hardware

2 Likes
3

Find a machine that supports Linux well which should be almost anything out there. Unfortunately binary blobs will be a must if you want wifi, suspend and 3D acceleration support.

You probably want to avoid machines with SSDs if you care about LUKS password management. On SSDs you can’t safely change compromised passwords because of the way wear-leveling works.

2 Likes
4

That’s a good point. Is it noted in one of the security guides?

Also, it is a reminder re: secure deletion of HDD/SSDs. The expert advice seems to be don’t bother with multiple writes over the drive (stuff can be left in various sectors?), but better to encrypt the whole thing and perhaps destroy the encryption header (?).

Let me know if this is right, and I can add both somewhere if needed.

1 Like
5

torjunkie:

That’s a good point. Is it noted in one of the security guides?

Only here, wear-leveling is mentioned, please check if complete.

Advanced Security Guide - Whonix

1 Like
6

Yep :slight_smile:

TRIM support does leak metadata about what sections of the disk are encrypted which could help some theoretical attacks so its discouraged and disabled in default Linux installs.

The problem is there is no way to guarantee the header is destroyed on SSDs because of how they are designed.

They’re already added but thanks. You’ve made some incredible contributions to the wiki. Thanks a lot

2 Likes
7

Thanks! It really sucks that you need a non-SSD for encryption to be effective, since that’s what you usually need for good performance with encryption. (At least that’s my understanding.)

It sounds like there’s not much one can do to avoid closed source crap. I figure if I can avoid having a video card, but that’s about it.

8

Encryption doesn’t really make your HDD slower but your CPU has to perform additional operations (decryption/encryption) when reading/writing data so it increases the latency a bit. Still sucks though as SSDs are faster in general.

Most CPUs nowadays have an AES instruction set and allow hardware virtualization (Intel VT-x or AMD-v) but you may still want to check if your laptop CPU really supports both.

9

late reply. but i’ve been thinking about this one a lot more lately as i wouldn’t mind getting a newer machine. cryptsetup offers the ability to use a gpg encrypted keyfile with /boot to open a / drive for a host.

yes, there is the issue with a killed keyslot not being removed from an ssd. however, the method i prefer for encrypting disks with luks is probaby a good mitigation technique. after you create your luks encrypted host, create a random 8192 byte keyfile as your next key slot. then, gpg encrypt it and have /boot on a small external device that is easy to hide, lose or destroy. use the gpg encrypted keyfile with cryptsetup to unlock your host root drive.

in this regard, a potential compromise of someone witnessing you type your passphrase is less of an issue, since you can simply create a new boot drive in private with a new random key as described above and then destroy the old boot key. without access to the old boot key, an attacker is going to have a harder time decrypting an old key found in the presence of an ssd, simply because there is no way you will know a random 8192 byte passphrase, which is what will be the attack vector on the ssd.

the only other catch is that, when creating the initial luks drive during an install, you need to choose a passphrase that is sufficiently random enough so that you absolutely will not remember it after you discard it in favor of the 8192 keyfile based keyslot. but, it’s very doable.

if i’m missing something here, please share. i’ve avoided ssds due to this problem. however, i think the above use scenario is likely sufficient enough to prevent the pitfalls of the persistence of data on an ssd. if an attacker sees you type a passphrase, it’s simply not the actual key to unlocking the drive unless they happen to apprehend you with a copy of the /boot drive, which will natrually have the gpg encrypted keyfile on it. and, obviously, you’ll likely know the passphrase to decrypt the gpg encrypted keyfile.

perhaps this is all security theater. but with the above steps, particularly given how people tend to find themselves in trouble when it comes to encryption, i’m not sure the risks are potentially greater with an ssd at this point. to combat compromise of a passphrase in such scenarios generally requires advance knowledge. if you are caught by surprise with a standard magnetic drive or sdd, game is basically over depending on how barbaric your attacker is.