New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I even setup LUKS on every VM I purchase. Normally I get a <=10% hit on performance, depending on the hardware on the VM or Dedicated.
I also setup LUKS, around 10% performance hit as @NotFoundException said. Trust no one
Yes
Always unless kvm/ ipmi/ console is missing
pray that your KS has working IPMI.
Otherwise just encrypt the storage pool for VM's.
The illusion of privacy. Yep.
Hmm. Yeah gotta check once
How is luks illusion? Serious question.
howto please
How? You RENT a box, first of all. If they can't directly access your data - they will plug into your network. If they see something sus - they will hunt you down and while you piss into shorts, you will willingly unlock that "private" stash of yours.
Anyway, you choose to sacrifice performance over illusion of privacy. It is your choice and I respect it.
If you use Ubuntu ISO, it's just a checkbox you need to check and set a password, that's it. Afterwards you can use something like dropbear to provide the key on startup remotely.
Why do you think it's a illusion? And why do you assume that others think it's covering all needs?
And what do you mean by plug into your network? If you provide the encryption key using dropbear it's encrypted and no one can see the traffic. They can't really spoof the server as the hostkey verification would fail.
On a VM sure, they can take a memory snapshot, read it out and find the respective key in the memory. But come on, you never cover 100% of the cases and it's just to negate most of them and this would mean that the provider themself would want to access your system.
Yep, encryption is a thing. Here, a nice read before bed https://notes.valdikss.org.ru/jabber.ru-mitm/
In the end, if some sophisticated way does not work - gov entities will come and knock at your door. Encrypt that.
Yes.
It depends. I doubt it would affect the performance much on a dedicated server. I use it on my Kimsufi and the drives are still the bottleneck achieving speeds around 800 MB/s (1m sequential) - no matter if encrypted or not.
I wanted to test how this affects the VPS servers as well.
At onidel, we've got quite fast drives so I thought I would do a small benchmark for you. Here the CPU was clearly the bottleneck. All tests were conducted on a 2 core AMD EPYC 7713, 2 GB RAM Premium VPS with 10GB ext4 filesystem mounted using
noatime,discardoptions. I used the defaultaes-xts-plain64cipher which is accelerated with AES-NI on modern CPUs.Unencrypted:
LUKS2 with 512 byte sectors:
LUKS2 wth 4096 byte sectors:
For high speed SSDs, you should always go with 4k sectors (
--sector-size 4096cryptsetup option when creating the LUKS2 container) whenever you can. I found, with larger fio block sizes they performed much better than the 512 byte sectors (which is still the default in most installers).You can verify your sector size with the command:
Note that the CPU was completely idle during the benchmarks. Normally, it's not possible to match the performance of an unencrypted drive as the encryption itself takes some CPU time when performing drive operations. As a consequence, the software you're running will have slightly less CPU to work with.
Personally, I think the performance of an encrypted drive is more than sufficient for my own workloads, even if it can't do 10s of gigabytes per second. I don't see any reason not to use drive encryption on my own servers.
Additionally, @Levi mentioned important point:
and you have no control over how your data will be erased after the service is cancelled...
Your example doesn't really make LUKS a privacy illusion and even when gov entities come to your door, you can just not decrypt it
The talk about network flow encryption is another and that's another attack angle LUKS is not used for, which makes your point useless. LUKS is just one thing to defend against certain angles, if you care, you should also monitor TLS certificate changes, hostkey verification etc.
They can just copy that hostkey from the server, can't they? And then just wait for you to connect and type in the decryption key.
It is an interesting angle a privacy is discussed here. There is no simple answer I am afraid. Encrypting virtualized environment may be considered an illusion since the node admin can easily get in should this be required. Encrypting dedi is a bit better in terms of privacy. I do not really understand the argument 'they will plug into the network' by @Levi I mean goodluck, let them plug anything into anywhere, if they want. Of course, if anybody will plug a soldering iron into your orifice, you will quickly give away all your passwords/keys.
Another interesting reason to encrypt is security. What happens if hardware will be stolen? In case of encryption it will preserve the data and it is very likely the data will be erased since the criminal will be after the hardware (with certain exception, probably).
Also, encrypting is a good learning curve.
What? How do you want to "just copy" that hostkey? It's a private key that's not shared. The attacker would need access to the current system, which you can just deny by firewall and/or SSH key only login.
And how would they do that? No password reset, SSH key automation without cloudinit or qemu guest agent. Password reset using any rescue system will also not work as the drive is encrypted. Like I said, the only option to have even a chance would be a dump of the VMs memory while running already decrypted.
Well I mean, also they could log/hack their own NoVNC or whatever, but all these cases are so hard to pull for a provider here on LET and most other providers, which makes it a not viable option. They would just go for a customer that doesn't use LUKS.
Thanks for the insight, that's a disk speed I haven't tested with and it's quite interesting how it scales. In the end it obviously depends on the use case, but let's be real, if you expect that much performance with LUKS you normally shouldn't go anything virtualized.
PS: Nice subliminal advertising, I like it
So what was the reason for encrypting the disk then? If the assumption is that an attacker can't get access to the system, you don't need to bother with encryption. But if the attacker can get access to the system, you haven't really achieved anything.
What are you saying, I don't understand? You obviously need to make sure no one can just login on your servers, you always have to. LUKS is just another encryption that helps your data to be safe from being read by the provider and third parties after getting your drives.
I think when the system is running, the key can be extracted from RAM like you said.
shhh
I mean I hope it isn't too bad... I genuinely tried to provide the OP with best answer (and benchmarks).
But yeah, normally i would probably be pissed at people doing that hahah
If an attacker can get the physical drives, they can just as well tamper with your pre-boot environment where you enter the decryption key (and trick you into revealing the decryption key - oops, there was a short power outage...).
Yes, it's possible:
https://github.com/nyxxxie/de-LUKS
https://insinuator.net/2025/07/insecure-boot-injecting-initramfs-from-a-debug-shell/
Yeah.. that's not a scenario disk encryption is supposed to help with. Once an attacker knows how to dump RAM and find the encryption key there, it is basically unencrypted.
However on dedicated servers with new DDR4/DDR5 memory it isn't as straightforward to perform from what I've heard.
OP never mentioned what the supposed threat model is, so not sure why we're talking about "well yeah but if you have a gun to your head by a government agency while being detained and waterboarded in a secret CIA black-site, you can still be compelled to unlock your server."
Many use LUKS for just general safety. Provider going out of business and the drives in your server ending up on ebay, next customer not being able to recover data from them from poor (or no!) disk wiping, etc.
How does one force this sectorsize while installing via iso? I dont recall seeing this option atleast on Debian/ AlmaLinux
Thoughts?
Always encrypt. LUKS on a dedicated server is non negotiable if you care about data protection. Physical access to unencrypted disks is game over.
For remote unlocking, Dropbear in the initramfs lets you SSH in at boot to enter the passphrase before the main OS loads. Minimal performance overhead since decryption happens at the block layer and modern CPUs handle AES NI in hardware. You'll barely notice it on any recent processor.
The real question is your threat model. Encryption protects you against disk seizure or a hosting provider snooping on decommissioned hardware. It does nothing if your running system is compromised.
You answered if for me with the last paragraph.
It's just general security if disk/s went somewhere and I don't own the hardware. I just rent it.
I want to protect that someone sees my small dick on self hosted immich 😂
Not all threat models that FDE is meant to protect against involve being stuck in the same room as an Mexican cartel who will stop at nothing to get at your data. That's like saying that it's pointless to wash your hands because a gram of anthrax will kill you dead no matter what you do.