Full disk encryption on SSD while running a node

So, if you're using full disk encryption while running a full Bitcoin Core node on an SSD, does all that intense I/O from downloading and verifying the blockchain put a lot of stress on the drive? I get the feeling that SSDs are a bit more reliable since they have no moving parts, making them a better choice for running an encrypted node compared to HDDs. But what should I keep in mind when picking out a drive? And what’s your take on built-in drive encryption versus going with software options like VeraCrypt or dm-crypt, which seem to be the go-to for most Linux distros? I kind of think it’s better to skip the built-in stuff and just use open-source software for encryption instead. I’m mainly curious if anyone’s tested full disk encryption on SSDs and if it’s actually safe for them. Also, what settings should I adjust to boost reliability?

Bitcoin Core I/O activity affected by amount of dbcache, where it's significantly lower if Bitcoin Core can load all UTXO into RAM. SSD also have high endurance, so i wouldn't worry about it unless you use cheap or shady SSD. It's the opposite, see https://superuser.com/a/1403790. But personally i wouldn't worry about it when FDE is being used. In short, 1. 2TB or higher capacity, since Bitcoin Core alone currently use about 700GB of storage. 2. Avoid QLC SSD. Once it's cache it's fully used, the SSD become extremely slow. 3. Avoid unknown brand or brand with bad reputation. Yeah, don't use built-in encryption offered by the drive. I doubt anyone actually audit it, since it's not popular (compared with dm-crypt).

Okay so I will stick to SSD even if it's not as resilient as HDD for this task, but man HDD is so damn slow nowadays that I cannot tolerate syncing a node from scratch again without SSD so I will pass. The question now is, what settings for dm-crypt? When im installing linux, with your average interface like Debian, it just asks you for some password, they don't give you any way to enter any details on what sort of encryption are you using. VeraCrypt was way better in this regard, but I think FDE with VC only works in Windows for some reason.

Yeah, HDD is very slow especially on random read/write task. Although with sufficient RAM (enough to store all UTXO), you can achieve fast initial sync/IDB on HDD. In fact I still store all Bitcoin Core data on HDD. Debian and few distro let you configure detail of the disk encryption during installation. As shown by screenshot from StackExchange answer (not mine), you actually can double-click specific configuration (such as key size) and select different available value. But usually i use default configuration provided by distro i use.

What version of Debian is that screenshot from? I remember watching tutorials, and in no point in time they asked you about any specifics, or I saw any possibility to modify the specification details for the encryption procedure. I only remember two passwords. One that was for the root admin setting, and another for the actual encryption and it was set in a confusing way where you didn't really know what the passwords were doing, so hopefully they changed this, since im talking some years ago. Im just going to get Debian 12 iso and try for myself. Im still asking what settings would be good to run a node at tho, since I want a security but also not blow up the drive from overdoing the encryption and then have it do heavy lifting with the node syncing process. If anyone is an expert in this field here perhaps you could recommend some better non-default settings?

That StackExchange answer mentioned it's based on Debian buster, which mean Debian version 10 (ten). But i can confirm such option also exist on Debian 12 installer, although it's still very easy to miss such manual configuration. I don't have good answer to your questions. But there are few things i can mention and suggest. 1. Run this command to know encrypt/decrypt speed on your device. 2. Use longer password, to make brute-force become unpractical. 3. Read this very long FAQ, https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions. But just like other people[1-2], i believe the default configuration is secure enough. [1] https://security.stackexchange.com/a/131105 [2] https://security.stackexchange.com/a/39309

What about partitions? Some people add swap partitions and some don't. There's also the discussion of if the boot partition should be encrypted too. I believe VeraCrypt encrypted the boot partition too when you did FDE, but default settings on these Linux wizards I believe they don't encrypt the boot partition. That just would be to make sure all partitions are encrypted. On the screenshot, it talks about a partition, but I assume since it says sda and not sda1, or sda2 etc.. that means it's referring to the entire disk that is being encrypted? As far as the speeds, they seem decent enough I guess, aes is the clear winner. I assume 256b key is enough and 512b isn't needed.

I'm not familiar with how VeraCrypt works. But whether you use VeraCrypt or dm-crypt (LUKS), you'll need at least one non-encrypted partition used to boot by your computer and decrypt other partition. I don't know, since i rely on guided partitioning. And AES is also widely used. But make sure to perform benchmark on your computer, since the encrypt/decrypt speed depends on your CPU.

For the drive there's no difference in I/O load whether it's gets encrypted or non-encrypted data to write to or read from. The OS does the encryption/decryption in memory, it doesn't matter for the drive what kind of data it gets to write to media or read from media. There's more load on the CPU as it has to do the encryption and decryption, but usually it can handle it without much notice for the user. This of course depends on the CPU you have. Most modern CPUs have built-in instructions for speedy encryption and decryption. Some drives do internal encryption with the advantage that you can erase such a full-encrypting drive in micro- or milliseconds. Full drive erasure simply throws away the internal encryption/decryption key. After that there's only garbage on the drive when you try to read it. My daily driver runs Ubuntu on an encrypted filesystem and it runs a full Bitcoin Core node all the time. I didn't tweak anything in particular and notice the full drive encryption (except for the tiny boot partition) only when it reboots and I have to enter the encryption/decryption passphrase. This is an old ThinkPad laptop, nothing too fast or fancy, just reliable and easy to service.

I did some tests (about a year ago). If I remember correctly, my laptop with 8 GB RAM wrote almost 5 TB to disk during IBD. That's a fraction of what a modern SSD can handle. In my other test, with 32 GB RAM and enough dbcache on a server with HDD, the disk speed was not a problem at all. More RAM can make up for a slower disk, problems arise when your disk is slow and you don't have enough RAM.

FWIW, there's small I/O slowdown on read/write benchmark even when your CPU is fast enough. See https://scs.community/2023/02/24/impact-of-disk-encryption/, specifically benchmark result on SAS HDD. Although it's small enough where most people won't even notice it. Do you post this reply on wrong thread or intentionally being off-topic? 1. OP never state he own any Mac device. 2. OP never mention or ask anything about connecting to Bitcoin node, so why do you mention RPC? 3. Other full node and application that use RPC-JSON protocol still can connect to your full node, even if FDE is enabled. So i don't understand why you mention Electrum server. If you have neither (fast disk or big RAM capacity), you probably better not force yourself to run full node anyway.

Sorry for being late to the conversation. I'm curious why you would want to encrypt the drive. You might want to put your wallet and perhaps bitcoin.conf on an encrypted drive, but I can't think of a reason to encrypt anything else. If you only have a single storage device, I bet there is a way that you can split it into two drives and make one of them encrypted.

Counter question: why not? If you're going to encrypt something, it's a lot easier to just encrypt the whole disk. It doesn't matter much for performance and you're sure you won't leave traces on an unencrypted partition.

What settings did you use for the full disk encryption settings? what Linux distribution did you use? In principle I will be using whatever debian latest version uses for full disk encryption which I assume to be enough, if not then please someone recommend some tweaked settings that make sense given the context that: 1) You must be running a node, so it will be a lot of i/o 2) You have to keep your bitcoin safe, so no compromise in trying to make things too lightweight on the settings to get less wear and tear due i/o It's one of those things, I guess there is a sweet spot of strong encryption that is impossible to crack realistically but not some insane settings that will turn your SSD into a toaster when it practice due diminishing returns you don't get that much of a return.

This test wasn't on an encrypted disk, but I don't expect it to matter much. If anything, I'd just use the default encryption (with a strong password).

From my understanding of disk encryption, this doesn't necessarily increase the write-load compared to an unencrypted disk. Why should it? The encryption is done in RAM and it makes no difference if your write a sector or whatever chunk of data encrypted or unencrypted to disk.