You know you're fucked if they use a wrench. That means you don't have to be seen publicly ever again. There's a chance for you if they're using a rubber hose...
Not much good if they only have your laptop and not you.
idk man, but I'd still much rather have encryption, even if I'm up against the alphabet boys:
What would actually happen is a bios level rootkit that installs a nearly invisible tiny rootkit on your device everytime it starts, but this is only if you are an important target. Most police departments can also just pay a private hacking company to steal your keys by using undisclosed exploits. Encryption can work well for other things but anything you wouldn't want state or corporations seeing, you are better off just not ever putting it on your machine.
You can be private somewhat through obscurity. Using free software that doesn't log you, not using any machine that's in anyway tied to you to do stuff, setting up your own point to point connection to use someone else machine as your access point. Never having a microphone or camera anywhere near your hacking machine. I'm not really that type of hacker, more of a programmer/hardware person, but it can be done somewhat safely if you take every effort to protect your identity.
This is what I would do if I want ed to do something on the internet that might actually really piss off the FBI and NSA. Something like releasing the Epstein files to dozens of independent journalists around the world or something.
I'd get cash, and leave my phone at home, go to a thrift store and buy an old laptop. Wait a couple of months, and never power it on. I download dozens of Linux distros a year before this, something as small as possible, and lightweight as possible. Nothing network, maybe even tails.
Then I'd have it sitting on a thumb drive for many months before I dropped the files. One day before a lot of rain was coming in, I'd walk, not drive or anything, without my cell phone, using the tree cover to avoid spy satellite rewind surveillance, to a location where there is open wifi or an Ethernet jack.
Then I'd use several layers of proxying and VPNs, although this would be slow as shit. All on fresh accounts. Using nested VMs, each carrying an additional layer of VPNs. I'd use this as my set up my own network, by exploiting some random machines in the wild to get my last couple layers of VPNs.
Being careful to only type one word per second and not misspelling anything or in anyway aiding in any type of correlation attack, I'd first upload it in an encrypted format to a web host to speed up the next part, then I'd copy it to many places. I would then send it to as many people as possible, probably using a script to hit many emails addresses at once. As soon as the files hit the drive, I would assume I had about 5 minutes before the black helicopters showed up. At 5 mines I'd take a super strong magnet and start destroying the laptop, then I'd run away, find another safe spot, and then incinerate it.
Then I'd never tell anyone, go home, take a nap, wake up, talk to chatGPT about my amazing nap that I overslept on, and carve out some hidden spaces at abandoned houses and stuff to stash the actual drives with the info.
If you do anything less then this, you will probably get caught. Legal evidence is one thing, but you should never underestimate the numerous surveillance technologies they employ for unconstitutional surveillance. You n leed to be mindful of fingerprinting, (using only a throw away device and destroying it afterwards in a way that it's not obvious that it was you) nothing that has ever touched your network or any files that that came from your PC or anything. It needs to exist in a totally separate universe. No connection whatsoever) you need to be mindful of cameras, license plate scanners, cellular modem surveillance, spy satellites which can see back in time to follow someone's footsteps back through time. Correlation attacks, common word usage that can denote your region, common misspellings that you do, the particular way you type, root kits, assume every device is compromised and if you buy a device with a camera, don't even open it until it's been sitting for months and then remove the cameras and microphones, and never power it up anywhere near your house.
Another thing to be mindful of is fingerprinting your downloads, don't download something on your PC and use it on your device.
Be wary of your footprints, this is why I said you would want to do this before a storm but perhaps maybe you would even tie wood to your shoes.
If you did this you could leak something like the Epstein files and probably get away with it, but if you are one of the few people who live in a neighborhood who is a hacker, I would expect that you'd have dozens of FBI agents watching every move you do and combing through your past to find any infraction that they could try to blackmail you with.
Never ever, trust an electronic device is better advice.
Encrypting your drives is a very sensible step to take, and it's so low effort that it's a no brainer in most cases. It'll stop casual thieves stealing you machine and reading your files, and combining your password with a TPM encrypted one will mean your data isn't readable on any machine except yours, even if the attacker has your password, which adds a little extra protection.
Unfortunately, none of that protects you against an adversary who is willing to kidnap and torture you to get your files. At that point you have to make a choice, which is more important; your files or your life/not being tortured. Fortunately, most people will never be in that situation, so should encrypt their drives and accept they'll reveal their encryption passphrase if taken hostage/arrested.
A more common case I've heard of is law enforcement using face id without permission. They can also compel people to give up passwords too which is why duress passwords and panic buttons exist to wipe everything
You want to think very carefully before giving a duress password, or using a destructive panic button when dealing with law enforcement. If you do, you will be charged with, at least, destruction of evidence. You have to decide if your data is worth that. A duress password that only decrypts part of your data is probably safer if twinned with deniable encryption, although you still risk legal trouble.
This is in the US, in a lot of countries, even in EU ones, refusing to reveal your password is used as part of the case against you (not as proof but as a suspicious attitude that can, combined with other facts, bring a certainty of culpability).
So be careful and check out your local laws before following US laws concerning this.
I was actually largely agreeing with you, but responding to the bit where you said:
It Protects your files in case your computer is ever stolen and prevents alphabet agencies from just brute forcing into your Laptop or whatever.
It'll stop alphabet agencies from brute forcing it, sure, but that's not how they would approach extracting the information.
I see ~~~you've~~~ the mod has deleted this comment thread though, so it's unlikely anyone else will see it.
As to your question about what technology would stop it, I think you may need to think differently as no technology will stop a determined enough opponent torturing you for a password, but they're much more likely to attempt a malware style attack against you to skip all that bother. So countermeasures would involve a well locked down system (think about things like SELinux with MLS enabled and using VMs to isolate processes) and good information hygiene practices to reduce the risk of infection and the risk of it spreading if you are infected.
That's absolutely possible, but there's not much you can do about that really. My point was simply in response to OP's assertion about encryption protecting your data from 'alphabet agencies'. It wont because it is very unlikely you consider keeping your data confidential more important than your life.
There is 0 chance tpms arent back doored.
Given its nature and functionality, it's hard to see how the TPM subsystem itself could be backdoored in any meaningful fashion without the rest of the CPU also being compromised. Whilst that is certainly possible, and the remote management engines (IME and such) almost certainly are, it seems more likely to me that the encryption algorythms themselves are deliberately weakened in some way. The NSA, famously, have done that sort of thing before, subtly influencing aspects of the design of cryptographic systems to make them easier for them to break. It would not surprise me, for example, to discover that the supposedly random key material is actually linked to something like your CPU's ID.
None-the-less, using functionality help prevent someone who has your password, but isn't a government actor, decrypting your data.
Pretty much all beginner friendly distros have this thing (Fedora Debian Ubuntu Mint). You just have to enable it. Also make sure if you are using secure boot - remove Microsoft keys and generate your own. Also its nice to have bios password setup too.
Watch out about removing Microsoft’s keys! Some video drivers (nvidia) will only work with Microsoft’s keys and you might brick your system. Only remove Microsoft’s keys if you know what you’re doing.
It's easy-- if you install on a single drive. If you want home on a separate drive, encryption is not so easy, and you have to learn about cryptsetup, crypttab, etc. Quite a steep learning curve compared to the installer. I do hope distros provide better coverage of this in the future. Having home on a separate drive and encrypted is just good practice.
And don't forget folks: if this drive contains your whole digital identity, make sure your next ones do have the keys. If something happens to you, it is impossible to retrieve logins, photos, whatever your kin/whomever might need from that drive.
Same goes for e.g. homeservers, VPSs or anything your family relies on: tell them where they find the relevant logins and who could possibly help them, if they're not capable. Grieving is hard enough, if they figure they also lost all memories of the beloved one, that's terrible.
Also: back in the day, you could wipe a drive with GNU Shred or just "dd if=/dev/zero of=/dev/hda". SSDs and NVMe drives have logic about where and what to overwrite that makes this less effective, leading to the possibility of data recovery from old drives. If the data is always encrypted at rest and the key is elsewhere (not on the drive, in a yubikey or TPM chip or your head), then the data is not recoverable.
From what I understand, some modern drives effectively encrypt everything at rest, but have the key on file internally so it decrypts transparently. This allows for a fast "wipe" where it just destroys the key instead of having to overwrite terabytes.
Dang, if those agencies ever see my Civilization 4 save games, I'll be so royally embarrassed that I spent so much time on it that they could blackmail me to anything.
Cryptomator is good but it's important also to keep backups of the unencrypted content of the Cryptomator vault that are not encrypted by Cryptomator. (You could encrypt the backups with another system.) Cryptomator vaults are more fragile than the underlying file system, and it's easier for a glitch in the sync process to corrupt them so they're unrecoverable. I have lost data due to this in the past. So it's best to make sure all the contents of your vaults also exist somewhere else, encrypted in another way.
It's not that they're especially fragile. It's really only when you combine them with a sync process. I once had a sync go wrong and it resulted in the contents of a vault being unreadable. Because all you have are a bunch of encrypted files with meaningless names and a flattish structure, which Cryptomator interprets and mounts as a different directory structure, when something goes wrong it's not easy to know where in the vault files the problem lies. You can't say "ah, I'm missing the documents folder so I'll restore that one from backup" like you could with an unencrypted directory. And if you've made changes since the last vault backup you can't just restore the whole vault either. You could mount a backup of the vault from a time when it was intact, and then copy files across into your live copy, but I feel safer having a copy in another format somewhere else. Not necessary, I guess, but it can make recovery easier.
Ok, I understand. In my particular use case that shouldn't be an issue. My Cryptomator folder is local and I use it only locally. Then there's a sync process to copy stuff to pCloud automatically, but that copy is never touched directly by my.
But in any case as you said, backups.
easy to use gui backup utilities (like pika and déjà dup) can also encrypt its backups
AES-256 is just an encryption algorithm, it doesn’t do any compression on it’s own, so it’s not quite right to say its compressed with it. Really it was compressed, then afterwards encrypted with AES-256.
Ideally, yes. The problem is that the non-advanced users then get prompted for their encryption key and then it's "What are you talking about, I never set that up, what do you mean you can't recover the photos of my grandkids!"
This makes a world of difference
Yep. Can't recover /home if you fuck around.
Keep it simple and stupid it is for me. I prefer to encrypt only my sensible files. And the browser runs in volatile memory.
I found that Limine (bootloader) has the fastest decryption when paired with LUKS at least for my laptop.
Limine does not have decryption, that's just the linux kernel.
I don't know, I don't see a lot of damage or unpleasantness stemming from someone getting into my /tmp, but I don't want any llm being fed contents of my /home. I am less afraid of an attack, as I am irked by corpos putting fingers into my shit
Also I am pretty sure I have at least some secrets in my shell history
Do both
I have seen the use of such a device by gov't agencies; basically a large UPS that clips onto the AC plug's prongs so that a running server or desktop PC can be confiscated without power being interrupted.
And what is the advantage of that?
Files are encrypted at rest, if they are not actively interfacing with the encrypted mount it is secure. If you encrypt your entire system it's safe from attacks when powered off, but as soon as you're booted in the machine is fully accessible.
I like to keep a key on a USB so the computer boots either with a ridiculously strong backup password or a key on a USB drive. I like tiny little USB drives. So, if you find yourself in an airport or wherever and you just "lose" the USB then the device is automatically locked down.
I built a small set of scripts to decrypt when the initrd starts and can load from a file in the initrd (from separate volume), EFI, or various combinations of passphrase in GRUB. The main intent isn't to keep out somebody with physical access to the machine and sufficient time but rather makes it a lot easier to make the data unrecoverable when the drive is disposed of.
That's one of the reasons why I installed OpenSUSE Tumbleweed on my Deck. I used unl0kr to put in my passphrase on boot. Unfortunately OpenSUSE removed the framebuffer device and the DRM backend doesn't work correctly at the moment.
Pointless for gaming devices, nothing to hide on them, there will also be a small overhead for nothing.
I use mine as a computer often. When I travel it stores notes, has my email accounts, and is a productive tool.
So yeah I would like to encrypt it. As it is I use vaults and back up encrypted to my own cloud. But it would be nice to simply do the whole thing.
Ok fair. But most of those tools are cloud based? Then wouldnt have to worry about an overhead lr encryption when the drive fails.
Encryption really is not much overhead with a modern processor.
I do believe the steam deck uses a modern processor with hardware cryptology.
your gaming account may be able to do some damage
Good question. Along the same lines, if your disk is encrypted and you make a simple backup (say using cp) is the backup encrypted and if so, how do you restore from that?
if your system uses full disk encryption (such as via LUKS) and you simply copy files off to an external or a secondary drive for a 'backup', no. the copy is not encrypted unless the destination has encryption set up on it, too.
the alternative would be using a backup program, instead of a simply file copy, that encrypts its backups.
It depends how the backup is encrypted. Most backup solutions will give you an encryption key, or a password to a key, that you have to keep safely and securely somewhere else. If you have an online password manager or a Keepass database in cloud storage, that would be a reasonable place to keep the key. Or on a USB stick (preferably more than one because they can fail) or a piece of paper which you mustn't lose.
the backup wouldn't be encrypted but you can use luks to encrypt the backup drive too, the same way as you'd do with a drive in your computer.
i use rsync to send off my /home to an encrypted backup drive and restoring it you just reverse the source and destination and copy the stuff back.
I started using borg backup the other day. It also keeps deleted files for however long you want, so it protects against accidental deletes. You can basically tell it the date you want to restore from.
It can also encrypt the backup for you.
dmcrypt for backup drives. Ideally with detached encryption header, stored separately.
Last time I had LUKS setup on my main laptop, there was a surprizingly sharp hit in performance.
I'm glad I have the option, but is it really the most appropriate thing for me to use right now? It just doesn't make sense to talk about security and privacy without a clear threat model first.
The type of partition I created was Debian's default settings at the time.
This is where the threat modeling comes in. The laptop in question is not currently likely to be physically searched - nor does it contain any data that is likely to put me at any risk if it is searched, and the more prudent things I can be doing to protect my privacy have more to do with getting away from Android/Play Store, and being less dependent on other surveillance-capitalism services like YouTube, Google Maps, etc.
I will likely use LUKS again in the future, but there are broader overhauls I need to make to my digital life first.
Currently I have fragments of my data stored on at least half a dozen devices that I've accumulated over the years. My digital life is as messy as my adhd brain. I plan on setting up a NAS at some point, and will likely both consolidate all my data there and use LUKS. But until then encrypting one drive is the least of my problems.
Although anti-theft tech in my laptop might be kind of neat.
What kind of CPU is in that laptop? The vast majority of x86 CPUs from the past 10 years include hardware acceleration for AES encryption so that the performance hit is negligible.
It's a Thinkpad P51 with a Xeon chip of some sort. Yeah I don't know what happened there, only that switching to fedora without full disk encryption has resulted in much greater performance, like a difference between being able to do some gaming or not. So many variable changed there that I don't even know if the crypto had anything to do with it.
Here is the guide for Fedora: https://docs.fedoraproject.org/...
arch linux was what forced me to use LUKS on all of my installs regardless of distros, btw.
i used the standard layout:/boot, /, /home, swap. So when the installs break, the best way to fix is to use the archiso and remount and re arch-chroot.
Well.... i found out that without LUKS, anybody can use any distros live cd and mount my stuff.
At first, I used LUKs only on the main partitions: so / and /home, or just / if no separate /home. Swap remains unencrypted. Boot is also unencrypted.
You could encrypt those too but need more work and hackery stuff:
encrypted boot: can be slow if you boot the compututer from cold. There's also this thing where you need to enter the password twice => think Fedora has an article to get around this. Iirc, it involves storing the boot's encrypted password as a key deep within the root directory.
encrypted swap: the tricky thing is to use this with hibernation. I managed to get it to work once but with Zram stuff, I dont use hibernation anymore. It involved writing the correct arguments in the /boot/grub/grub.cfg. Basically tells the bootloader to hibernate and resume from hibernation with the correct UUID.
The same issue applies to Windows 10. I think the TPM (and a BIOS password) is supposed to address this for Windows 11 but I presume you could flush the NVRAM and access the files anyway. I don't know what exact safeguards there are.
Either way, I am far more trustful of passwords I enter myself. Such as wafersGeezAfterCraze.
Encfs + pam mount home.
/tmp and var/run in tmpfs
No swap.
I wanna encrypt my BTRFS system, but not the FAT32 boot part. Only the Linux kernels are on FAT32 anyway, and I don’t care about encrypting those — they’re public stuff, not private files. I just let limine-entry-tool hash them to make sure they’re clean for booting, that’s totally fine for me.
I don’t like putting kernels on the Linux filesystem for GRUB — it just makes booting slower and causes random issues.
Yeah but then you need to type in two passwords. A little annoying
It's quite possible to set up LUKS with a USB key instead.
What if they get your laptop and your USB key then
Obviously that would be a total compromise. However this all depends on your threat model and how you usually use your laptop, and if someone were to steal it, would they also mug you for your flashdrive?
In my case, I just type the passphrase I have into the laptop, although my homelab server uses a USB so that it can unattended reboot, and I can put the USB in a secure location if it doesn't need to reboot unattended.
Otherwise, in my case I usually go out with a laptop that if stolen, is only worth about $150 AUD so not a big financial hit. While I have LUKS as a passphrase, I'm not likely to be a target of any individual or entity that, if they really wanted my data, would also mug me for a USB key, so I could live with either.
That's what TPM is supposed to solve. As long as nothing changes on the PC you don't have to input a decryption password and access is protected by your usual user password.
On one of my computers I have LUKS and requires me to type in two passwords. Not sure if it has TPM
Could be a misconfiguration. Can happen when you have more than one partition that is encrypted. Grub would decrypt only root and fail to pass through the passphrase to decrypt the others. Can be fixed by putting a decryption key somewhere on the root partition and adding that to the other partitions.
That's definitely not how it should be, unless you have two different passphrases.
thanks for using Leebra!
go to feed...
Inserting relevant XKCD as is required by internet law: https://xkcd.com/538/
save