On Sat, Feb 14, 2026 at 07:01:52AM +0000, [email protected] wrote: > On Sat, Jan 24, 2026 at 04:21:28PM +0000, Crystal Kolipe wrote: > >On Sat, Jan 24, 2026 at 04:09:25PM +0000, [email protected] wrote: > >>With the SSDs that are present on nearly all servers these days, > >>deleting data from the disk (e.g if it fails or if the disk is replaced) > >>is not possible to do reliably. The only solution is to encrypt all > >>system data (root, swap, etc) and then destroy the encryption key once > >>the disk is no longer needed. > > > >If that is the problem you are trying to solve, you could simply use a > >hard-coded passphrase or a keydisk volume on a permanently connected USB > >drive > >or even the same disk, (depending on the exact level of destroyability you > >want for the key data). > > Permanently attaching a USB drive to a server rented in a remote > datacenter from a large provider
This is the first time in this thread that you've mentioned the server being in a remote datacenter that you don't have physical access to. The most obvious solution to this aspect of the problem is to rent a dedicated server in a datacenter where only you have access to your machine. In practice, depending on what services are available 'locally', you might have to rent a minimum of something like 4U of space to get your own 'locked box', but it's certainly possible. That is by far a high enough level security for the majority of people. Note that you need to consider this even in the case of using a passphrase at the bootloader, because if anybody has physical access to the machines they could just write a custom MBR which loads code to log your 'keypresses', and write it to the boot disk. You'd see ten minutes or so of downtime, which could be passed off by the malicious party as a hardware problem. > At the very least, it will require coordination with the > hosting provider and payment of "remote hands" fees to have one of their > engineers insert your USB stick in the server you rented from them. So you want a high level of security, but don't want the fees associated with that? In that case, just rent any old cheap server and use it to relay encrypted traffic to a machine in your own home on your home DSL line. If your residential ISP does not allow arbitrary inbound traffic, use an IPSEC tunnel to the server. That way, the server never sees any decrypted data or the keys. Even if somebody compromises it and fakes a connection to your server at home, they can't do anything more than anybody could do by compromising any other piece of network hardware along the path. > What's more, it makes it impossible to reliably destroy the encryption > key -- how do you ensure chain-of-custody and destruction of the USB > stick once the server is decomissioned? If you've followed my suggestion to rent a server in a datacenter where you have physical access, then you can go and remove the USB drive yourself. If not, (presumably due to cost), you first overwrite it at the raw device level whilst still connected to the server. This already gives a high degree of confidence that the key has been destroyed. The removal and delivery of the usb drive introduces a small but non-zero level of risk. > Putting key material on the same disk does not solve the problem, since > data destruction on an SSD cannot be assured. Therefore, any plaintext > key material on the disk cannot be reliably destroyed. This negates the > whole point of the exercise. Please _read_ and _understand_ what I post before replying. I specifically qualified the idea of storing the key material on the same SSD: " depending on the exact level of destroyability you want for the key data " If you have a 4 Tb SSD, and it is either unencrypted or encrypted but you have the key to decrypt it, then you potentially need to reliably overwrite and therefore destroy 4 Tb of data. In that case, it's plausible and even likely that useful scraps of data would still survive on the flash memory chips, below the logical level that the SSD controller presents to you as a block device. At that point you already need a fair amount of knowledge or resources to retrieve that data - either a custom firmware, or the ability to remove the flash memory chips and read data directly from them. Not really a job for a home hobbyist. But a plausable risk does still exist. On the other hand, if you have a 4 Tb SSD, and it's encrypted with an encryption key that is stored on the same device, then you only need to adequately overwrite the blocks holding the key data. As long as those blocks are overwritten, the key is effectively destroyed. For somebody to retrieve the key data after overwriting the SSD at a block deivce level, all of the following would need to be true: * The key data survived the overwrite because one or more copies of it were stored in flash memory blocks that the SSD did not make accessible as part of the logical block device it was presenting. * Either somebody has enough knowledge to write a custom firmware to read those blocks, or enough knowledge and sufficient equipment to physically remove the memory chips and read them manually. * They are able to identify the key material within 4 Tb of random looking data. * Useful encrypted data, (that they can now decrypt), survived the initial overwrite. Are you saying that this is not an acceptable level of security for your data? > >If you have a specific threat model that you are trying to protect against, > >and you believe that the only thing preventing you from doing that is the > >inability to enter a passphrase at the bootloader without being at a keyboard > >which is physically connected to the server, this suggests to me that your > >logic is flawed elsewhere. So it might be worth explaining exactly what you > >are trying to do. > Remote unlocking FDE using dropbear-initramfs is standard practice with > other operating systems, and is widely supported as a solution to the > problem of un-wipeable SSDs. That is just a statement about 'other operating systems'. OpenBSD is not 'other operating systems'. You have not explained your threat model, so you have not answered the question that would allow me or anybody else to give you suggestions or advice for configuring an OpenBSD system to do what you want. > The other solutions presented in this thread are either clever but > unsupported (using TPMs) or impractical and fail to meet all > requirements (USB stick). If you consider dropbear-initramfs to be a solution to your threat model, (which you have not elaborated on), then why not use an OS that supports this mode of operation? Note that there are a large number of OpenBSD installations in diverse places all over the world, many of them performing critical security related duties. Everybody else seems to have found an adequate solution to the problem you are claiming exists.
