Solved What kind of encryption do you recommend?

I am new to BSD. What I'd like to do is mirroring two SSDs and encrypting everything that is possible. I mean the entire OS and even the swap partition (I guess BSD has one too). As far as I understand as long as the motherboard does not support booting with encrypted disks I have to keep the boot loader unencrypted. With secure boot I can check if nobody tampered with the boot loader, so that part is fine. I am not sure what boot loaders you use and what they support. As far as I know GRUB supports only ZFS + LUKS, but not ZFS native encryption. I would rather stick with ZFS native, because with LUKS both disks are encrypted differently, which means double CPU usage. Another reason that I suspect that ZFS mirrors and checksums the encrypted content, which I think is better than mirroring and checksumming the unencrypted one, but maybe I am wrong. Now I read about GELI full disk encryption too, but I assume that isn't built into GRUB either. Do you have a better boot loader I could use or maybe a better solution?
 
Have you read Encrypting Disk Partitions in the Handbook? Not sure if native encryption in (Open)ZFS is ready.
Thanks I found that. I just thought it is not up to date because it does not contain anything about LUKS. Now I am reading that LUKS is Linux specific and BSD guys use GELI. I'll read it. Meanwhile I tried to find the OpenZFS version FreeBSD uses so I could check if native encryption is supported, but had no luck. It looks like that info is not online, so I should install FreeBSD to read the version from terminal. I just wanted to decide about the formatting, encryption, init system, etc before that... Is it possible to run FreeBSD from pen drive? I assume not because it uses ZFS. I guess I really need to read more from the Handbook.
 
I think what we have here is an XY problem. You are asking us how to implement a certain solution. But you don't tell us about your problem. What attacks are you worried about? What information is stored on the machine you want to protect? What is the connectivity of the machine? What is the workload on the machine? What hardware are you planning on? Do you have a plan for storing the encryption keys securely? What other security measures are you planning on? Just as an example: you said you are worried about the CPU usage of encrypting the two mirrored disks separately, but you didn't tell us whether you are worried about the CPU usage of ZFS checksumming, or of doing RAID in software in the first place.

Just as one crazy and hypothetical example: Say you implement a whole-disk encryption solution using GELI, for a single laptop, which you are carrying with you. You store the encryption key in your brain, and type it in when booting, and then the OS runs until you perform a shutdown, and for that "session" the OS can decrypt the disk, and access your data. While you are sitting in your living room with that laptop, a burglar walks in, armed with a 9mm pistol, and demands that you hand him the laptop without first shutting down. Are you worried about that attack vector? How are you going to protect against it? Are you going to also buy a 10mm or 11mm pistol? What do the gun control laws in your country say about you (a law-abiding citizen) buying an 11mm pistol and having it sitting on a desk next to you whenever you use your laptop?

I deliberately picked a ridiculous example to demonstrate that instead of helping you with the minor technical issues of configuring GELI or ZFS encryption, we probably need to first help you think through what you are protecting, against what, and how.
 
Is it possible to run FreeBSD from pen drive?
Absolutely. I am currently using a M.2SATA to USB stick with 256GB.
I like that I can dump my UFS filesystems to my NFS server while booted off my USB stick.
It also has enough room to dump UFS partitions to it directly.
I even use it to backup NTFS filesystems.
A regular USB3 stick can be used but lately I have been using M.2 drives in a USB adapter.
Faster and cheaper than similarly sized USB sticks.
Aluminum 80mm USB3 to M2 adapter costs around $15 and 256GB M.2 around $40.
I like the Type A USB type with no cord. Slightly heavy on the jack but OK.


I use Ed25519 for my ssh keys.
 
I think what we have here is an XY problem. You are asking us how to implement a certain solution. But you don't tell us about your problem. What attacks are you worried about? What information is stored on the machine you want to protect? What is the connectivity of the machine? What is the workload on the machine? What hardware are you planning on? Do you have a plan for storing the encryption keys securely? What other security measures are you planning on? Just as an example: you said you are worried about the CPU usage of encrypting the two mirrored disks separately, but you didn't tell us whether you are worried about the CPU usage of ZFS checksumming, or of doing RAID in software in the first place.

Just as one crazy and hypothetical example: Say you implement a whole-disk encryption solution using GELI, for a single laptop, which you are carrying with you. You store the encryption key in your brain, and type it in when booting, and then the OS runs until you perform a shutdown, and for that "session" the OS can decrypt the disk, and access your data. While you are sitting in your living room with that laptop, a burglar walks in, armed with a 9mm pistol, and demands that you hand him the laptop without first shutting down. Are you worried about that attack vector? How are you going to protect against it? Are you going to also buy a 10mm or 11mm pistol? What do the gun control laws in your country say about you (a law-abiding citizen) buying an 11mm pistol and having it sitting on a desk next to you whenever you use your laptop?

I deliberately picked a ridiculous example to demonstrate that instead of helping you with the minor technical issues of configuring GELI or ZFS encryption, we probably need to first help you think through what you are protecting, against what, and how.

I'll store personal data and my projects from the last 25 years on this server. I'll write some sort of search engine for them, because I can no longer find maybe half of the things I want to. It is just too much data for a hierarchical file system, I'll implement some sort of tagging and experiment with semantic search, natural language processing, etc. Doing the encryption twice is maybe one percent of extra CPU usage, not a big deal, but I'd rather avoid it, because it is totally not necessary and I don't like wasting CPU time and power. Another thing, that if there is bitrot or somehow one SSD is damaged, then if the encrypted data is checksummed it is a lot easier to restore it as far as I understand. There is a very low chance that anybody will steal my server, still if that happens I don't want anybody to be able to access my data. So this is more about practicing these technologies and doing it the best I can, so later I won't have problems doing it by serious projects. Not to mention that I am a perfectionist. The server has an 500/25 internet connection currently. I plan to run a VPN server on it to be able to access my home network remotely. I think mirroring the data and checksumming is necessary if you want to preserve it intact for a long time. https://en.wikipedia.org/wiki/Data_degradation We have very strict gun laws. I could buy a gun after several trainings and psychological tests, but people normally don't do that here. :) I understand that most people think YAGNI, but I still want to do it. :)
 
Absolutely. I am currently using a M.2SATA to USB stick with 256GB.
I like that I can dump my UFS filesystems to my NFS server while booted off my USB stick.
It also has enough room to dump UFS partitions to it directly.
I even use it to backup NTFS filesystems.
A regular USB3 stick can be used but lately I have been using M.2 drives in a USB adapter.
Faster and cheaper than similarly sized USB sticks.
Aluminum 80mm USB3 to M2 adapter costs around $15 and 256GB M.2 around $40.
I like the Type A USB type with no cord. Slightly heavy on the jack but OK.


I use Ed25519 for my ssh keys.

Sounds fun, I look into it. I just read that some people tried to run it from RAM too.
 
I'll store personal data and my projects from the last 25 years on this server.
So the data is not very high value, and you are unlikely to have the italian mafia, russian KGB or american CIA come after you. Because there is no protection against those kind of attacks. That makes sense. You are worried about someone physically stealing your computer (or perhaps just one of its disks, although that seems implausible), rebooting it, and being able to read your data. Note that you are NOT worried about someone hacking in remotely while the computer is running, because once booted and you are logged in, encryption doesn't help you.

You are going to store the passphrase used for decryption in your head, or on a piece of paper? Because otherwise, you have to set up a key management infrastructure, which is quadratically harder than setting up an encrypted computer.

And you are doing this all as a hobby, just to prove that it can be done. Because if you were doing it professionally, there are much better and easier solutions. For example, buy a Lenovo or Apple laptop, configure it with a boot password (the BIOS password) using the original Lenovo-provided SSD, and you have a hardware encrypted disk: without the boot password, that SSD itself is unreadable. Doing hardware encryption at the disk-drive level (that's called SED or self-encrypting drives) is very hard for amateurs, and still very hard for seasoned professionals (been there, done that, as a file system developer, and will never do that again, it cost a few people their job, it cost my employer several customers, and was generally a bad scene).

In that case, there is no point encrypting the boot partition and the OS itself (stuff like /usr, /etc and /bin), because there are no secrets there. I would just let the machine boot normally without GELI, and then only encrypt the two partitions (one on each SSD) that /home is on. That just makes life so much easier, no hassles with when the passphrase needs to be entered only when logging in, and one can do system administration without worrying about all the encryption stuff. However, that does leave the problem of the swap file. I have no idea, but is it reasonable to run FreeBSD without swap file, if one has enough RAM?

... and I don't like wasting CPU time and power.
Of all the resources we have a shortage of, CPU time is the least of the problems. I would invest CPU time to save manpower and storage any day.

... then if the encrypted data is checksummed it is a lot easier to restore it as far as I understand.
Nope. Checksumming is to deal with silent disk failures, memory errors, and software bugs (which today are a bigger source of data loss than hardware problems). With RAID (of which mirroring is the simplest version), we have mostly eliminated individual disks from the data reliability big picture. The next thing to tackle is memory, networking (including things like disk interfaces, SATA and SAS...), and this is where checksumming helps.
 
You are worried about someone physically stealing your computer (or perhaps just one of its disks, although that seems implausible), rebooting it, and being able to read your data. Note that you are NOT worried about someone hacking in remotely while the computer is running, because once booted and you are logged in, encryption doesn't help you.

Well the value depends on who you ask. For me it is important, but I don't expect the CIA to show up. I will access my home network through a VPN server, only that will go through the firewall, so I don't think I'll have outside attacks, or if I'll have them, then I don't think I'll have the knowledge to stop them.

You are going to store the passphrase used for decryption in your head, or on a piece of paper? Because otherwise, you have to set up a key management infrastructure, which is quadratically harder than setting up an encrypted computer.

I have pretty good passphrases I can easily remember. I won't need password management.

And you are doing this all as a hobby, just to prove that it can be done.

My main area is programming, not hosting and this is just a hobby project for my home server. I don't think I'll do hosting professionally any time. The most I would do is running some AWS EC2 instances with the webservices I wrote.

Because if you were doing it professionally, there are much better and easier solutions. For example, buy a Lenovo or Apple laptop, configure it with a boot password (the BIOS password) using the original Lenovo-provided SSD, and you have a hardware encrypted disk: without the boot password, that SSD itself is unreadable. Doing hardware encryption at the disk-drive level (that's called SED or self-encrypting drives) is very hard for amateurs, and still very hard for seasoned professionals (been there, done that, as a file system developer, and will never do that again, it cost a few people their job, it cost my employer several customers, and was generally a bad scene).

I do partially because of the challange. I read about SED recently, but I don't like the idea. I would rather move the boot loader along with the encryption unlocker module to the NVRAM on the motherboard, but maybe that is too extreme. Somehow I don't like the idea, that on one of my drives there is a 100MB FAT32 partition just to store the boot loader and cause asymmetry. I don't have OCD, but I like order and perfectionism in my projects. My idea was, that the disks will contain only encrypted data and will be perfectly mirrored. With LUKS I don't get that, because I make two block devices with different encryption parameters and the mirroring would be done on a lower level after I unlocked the encryption. With ZFS native encryption I think the mirror would be above the encryption level. At least it can be implemented that way too, I am not sure how they did it, but it makes sense only this way if you ask me, because one can verify the block checksum and fix the errors without decrypting the data this way. So it would be the best solution to use ZFS native encryption. But I read about it, and it looks like only FreeBSD 13 will support it.

In that case, there is no point encrypting the boot partition and the OS itself (stuff like /usr, /etc and /bin), because there are no secrets there. I would just let the machine boot normally without GELI, and then only encrypt the two partitions (one on each SSD) that /home is on. That just makes life so much easier, no hassles with when the passphrase needs to be entered only when logging in, and one can do system administration without worrying about all the encryption stuff. However, that does leave the problem of the swap file. I have no idea, but is it reasonable to run FreeBSD without swap file, if one has enough RAM?

I don't know. I have 8GB ECC RAM currently, but I can buy another 8GB if necessary. I am not sure if running without swap affects stability. I know that running Windows without pagefile is a really bad idea, but Linux and I assume BSD might not require it. Any experience what happens when you run out of RAM with FreeBSD? Does the OS collapse or starts to kill non-vital processes? I guess I can set somehow memory limits for different applications which would prevent too much RAM usage. I am pretty sure it can be solved.

I'll read more about GELI, it would be nice to encrypt the OS too if possible. Maybe the bootloader supports GELI somehow. I know that GRUB2 has a module for LUKS, so it is possible to encrypt root. Otherwise GELI is fine, I read that it uses 128 bit AES in CBC mode (OCB would be so much better, but nobody is using it). I guess GELI is similar to LUKS, so it must be above the ZFS and I need to decrypt to be able to verify checksums. I would rather avoid that if possible.

Checksumming is to deal with silent disk failures, memory errors, and software bugs (which today are a bigger source of data loss than hardware problems). With RAID (of which mirroring is the simplest version), we have mostly eliminated individual disks from the data reliability big picture. The next thing to tackle is memory, networking (including things like disk interfaces, SATA and SAS...), and this is where checksumming helps.

Afaik ZFS crashes by memory errors and it can even corrupt data, that's why I bought ECC memory. https://research.cs.wisc.edu/adsl/Publications/zfs-corruption-fast10.pdf Not sure if that is still true, but better not to risk it.

Mirroring is not enough against bit rot. One needs block checksumming to be able to decide which copy is the right one and which copy is damaged. Modern file systems like ZFS, BTRFS, HAMMER2 verify checksums and can fix errors automagically if we use their "software RAID" solutions. ZFS uses SHA1 for checksumming, BTRFS uses CRC32, I am not sure about HAMMER2, I thought about installing DragonFly, but it is a too small project to be both stable and up to date.

I am not sure why you mentioned networking. Afaik TCP packets are checksummed and resent if there is an error. If you meant data cables like SATA, then yes, they can be faulty too. Not sure what protects against that maybe praying. :) There are some SATA cable testers available, but I have no idea if they are working because they are totally noname Chineese gadgets. I rather buy quality cables than testers.

Of course all of this is not enough if you don't have a good backup solution. :)
 
Afaik ZFS crashes by memory errors and it can even corrupt data, that's why I bought ECC memory. https://research.cs.wisc.edu/adsl/Publications/zfs-corruption-fast10.pdf Not sure if that is still true, but better not to risk it.

Careful, your wording might mis-characterize Yupu's work. What he (and his advirsors Remzi and Andrea and their colleagues showed) is that if you inject a lot of memory corruption then (a) ZFS will crash, and (b) ZFS checksums will not always protect the data. The first thing they showed is that ZFS handles *ALL* disk corruptions as well as can be expected: if extra copies of corrupted blocks exist (either on disk or in memory), it will use them; if no extra copies exist, it will return errors to the user gracefully, and disk corruption does not spread via metadata. Second, as far as memory corruption is concerned, they showed that the page cache is not protected by checksums (so if data is corrupted after an application puts it in the page cache but before writing to disk, there is nothing ZFS can do). What I've always known is that not all ZFS metadata in memory is protected by checksums (because of the compression/transcoding boundary when metadata goes to/from disk). So if a memory error corrupts metadata, bizarre things can happen, up to and including data loss and crashes. Having helped implement a file system myself, I understand how difficult (bordering on impossible) it is to protect all metadata in memory with checksums. At some point, if one wants that kind of reliability, hardware ECC is the correct solution.

Mirroring is not enough against bit rot. One needs block checksumming to be able to decide which copy is the right one and which copy is damaged.
Most of the time, one does NOT actually need checksums to prevent data corruption in mirrored systems. That's because traditional RAID design assumes that disks have good error detection mechanisms, and will not *silently* return wrong data. In a nutshell, the assumption is that a disk will either return the correct data, or a read error. Silent corruptions, where a disk does return incorrect data, are exceedingly rare, if you use quality disks and treat then well (vibration in particular, to prevent off-track writes). So most of the time (probably 99.99...% of the time), mirroring in and of itself is sufficient. But modern disks are very big, and any statement that is true only 99.99...% is not good enough. To quote a former colleague: in a sufficiently big system, everything that's unlikely happens all the time, and everything that's impossible happens occasionally.

I am not sure why you mentioned networking.
Sorry, that was a confusing term: I include things like SATA and SAS cables in that category. I've seen data corruption by bad cables; we had a SAS cable that would run fine if you disabled SCSI block checksums (a.k.a. T10DIF), and cause errors if you enable them. Note that these were *not* low-level CRC errors detected by the serialization hardware at the SAS layer, but errors that made their way all the way through the protocol. To build a reliable system, you also have to use high-quality hardware.

Afaik TCP packets are checksummed and resent if there is an error.
Yes, but the TCP checksum is only 32 bits. In a modern system, a lot of packets cross the Ethernet. We did this calculation once for fun, for a medium-sized supercomputer of about 10 years ago: If you reprogrammed all Ethernet cards in the computer to transmit only packets with random numbers as CRCs, then roughly once a second a packet would be (wrongly) accepted. That's because per second, roughly 2^32 Ethernet packets were being transmitted. This is effectively saying that even a blind chicken will occasionally find a grain, and if you have an army of very fast blind chickens, they will eat the grains pretty quick.
 
So if a memory error corrupts metadata, bizarre things can happen, up to and including data loss and crashes. Having helped implement a file system myself, I understand how difficult (bordering on impossible) it is to protect all metadata in memory with checksums. At some point, if one wants that kind of reliability, hardware ECC is the correct solution.

Yes, I understand. Every software has its limits and writing a good file system is not easy. I completely agree that we need ECC. Even for 1 TB silent errors can happen if you store data for decades.

Yes, but the TCP checksum is only 32 bits. In a modern system, a lot of packets cross the Ethernet. We did this calculation once for fun, for a medium-sized supercomputer of about 10 years ago: If you reprogrammed all Ethernet cards in the computer to transmit only packets with random numbers as CRCs, then roughly once a second a packet would be (wrongly) accepted. That's because per second, roughly 2^32 Ethernet packets were being transmitted. This is effectively saying that even a blind chicken will occasionally find a grain, and if you have an army of very fast blind chickens, they will eat the grains pretty quick.

Well, checksumming is based on probabilities, so we will always have a system where it is not sufficient.
 
I read about the topic a lot in the last few days. What I found is intersting with my limited Unix knowledge. It turned out I need at least the kernel and some sort of in-memory root like initrd to be able to boot properly, so those cannot be encrypted. I need to support the actual encryption ofc. and I need to get the keys somehow from the admin. All of these unencrypted parts must be packed into an EFI file, that the UEFI can verify with secure boot and load after that.

It is relative hard to rebuild that EFI file after every kernel upgrade. It is possible to split it up with a boot loader that supports signature verification before loading something. In that case the boot loader and its configuration must be signed. With GRUB and Linux it is possible to find such solutions. https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd Another option is having a different kernel just for decrypting the system. In that case we don't need to modify the EFI file by kernel upgrade, but it is a challange to give the control to the second kernel. Linux ppl use kexec for that, but even with that one needs to give the encryption keys to the second kernel somehow and solutions I found for that are pretty much insecure, for example: https://github.com/flowztul/keyexec writes the keys to the disk as far as I can tell and even if it removes them after that, they can be stolen with tools designed for restoring removed files. Afaik FreeBSD has something like kload, which should be similar to kexec, but I haven't had the time to read about it. I guess even with that I won't be able to solve the problem this way, so better to stick with the first solution, which is having a boot loader that can verify signatures and updating the kernel file and its signature after every kernel upgrade. That can be done by a hook automagically, but I need to store the private keys on the encrypted partition, which is slightly less secure then signing the boot loader only once and store the private key for signing in a pendrive which I never mount again.

I think these solutions are effective even against the "evil maid attack" https://en.wikipedia.org/wiki/Evil_maid_attack where the attacker not necessarily steals the hardware, but adds some unwanted software to it to get the keys. Even with this protection it is possible to get the keys as simply as hacking the keyboard. With software I think it is very hard to attack this solution. We could try to inject our code between the EFI file and the encrypted system if it is possible to force the boot loader to load that instead of the system, but it is unlikely that this can be done.

We might want to add remote unlocking so for example we could wake up and unlock the server after a power shortage even from a different country if we move the VPN server to the router. This is a very useful feature, but it opens up new ways to attack our system, mostly maid in the middle (MITM) like attacks. =] It is typical in Linux systems to add some minimalist SSH server like dropbear to the boot loader, but the private keys of that server must be unencrypted, so our maid can esily get them. After that she can try to do ARP poisoning for example. We can detect that by watching ARP communication: http://blog.sevagas.com/?MITM-arp-spoofing I guess there are many other ways to do MITM on such a system and I guess it is impossible to protect against all of them. There are other ways to access our remote system. Many server boards contain a thing called BMC. It is some sort of small computer built in the server to monitor it. As far as I know it has a dedicated ethernet port and can be accessible through IPMI possibly on a different network. Unfortunately my home server is built on a workstation motherboard, because it had half the price compared to server boards and I heard that IPMI implementations have a lot of vulnerabilities, so I decided that I won't need that feature. Some people claim that there is another way to send the keys something called serial network interface (SNI). I did not find much about that. As far as I understand it is converting network communication to serial one. I guess it is better because we won't need network drivers for it, and serial communication is supported by the kernel. I would skip this type of very low level solutions, because they need a lot of expertise I guess and as far as I can tell having network communication in the boot loader is no longer an issue in most of the cases.

So if we need remote unlocking, then there is a good chance our evil maid will steal our encryption keys along with the data and we might not even notice it. For me the remote unlocking is currently more important than protecting my system against evil maids. I just want to protect it against attackers who steal the drives and try to decrypt the data. Which means that they have access to the hardware only a single time, I notice that they stole my disks and they don't have the keys to decrypt the data on them. Protecting against such attacks does not require full disk encryption. All I need is encrypting the data and the swap. Though I tried to find a solution that does full disk encryption with split up EFI file and detached signatures, something similar I already linked about GRUB+ LUKS https://ruderich.org/simon/notes/secure-boot-with-grub-and-signed-linux-and-initrd , but I had no luck. According to the handbook geli supports full disk encryption https://www.freebsd.org/doc/handbook/disks-encrypting.html , but according to the forum it doesn't. https://forums.freebsd.org/threads/bring-up-networking-earlier-during-boot.49227/ Maybe that forum post is outdated, I don't know. I'll read the manual of geli later to find out, but even if it is possible, I'll need a boot loader that can verify signatures, can get the keys through SSH and supports geli and ZFS. While it is possible to have such a boot loader I think it is unlikely there is one, because it is not advertised. Google cannot find it or I do something totally wrong. :)

I asked about ZFS native encryption too. As I thought with that ZFS can verify encrypted blocks. So unlike geli (or LUKS in the case of Linux) it does not have to decrypt data to be able to verify signatures and fix the corrupted data if there is redundancy. From performance perspective this might not matter that much. I don't know. It looks like ZFS native encryption supports comes only with FreeBSD 13 and based on the release history I would expect that in late 2021 or early 2022. So ZFS native encryption would be nice, but it is impossible currently in FreeBSD. Even with GRUB and Linux it would not be that stable, there are still unsolved issues in the git repos if I check. So we can revive this perfect full disk encryption topic in 2022.

For now I think I'll do what you suggested, which means encrypting the swap and data with geli and leave the rest of the system unencrypted. Some people claimed that the best way to do this with data is having an encrypted jail partition and use ezjail. https://forums.freebsd.org/threads/bring-up-networking-earlier-during-boot.49227/ I am not entirely convinced about that, but I'll check. I don't think I'll do secure boot either, it makes no sense with an unencrypted system unless I sign and verify every single file. Without built in support I don't think I will do it. I think this is sufficient for my goals and in practice there is no better solution I know of if I want to stick with FreeBSD. I think I want to, I tried to communicate with Alpine developers a few years ago, but people here are a lot friendlier. In my experience this is generally true for all Linux, I have no idea why.
 
Looks like TPM could be used to store the private key for SSH, so even that can be solved securely and it might worth the effort. I have an MSI c236m, which has a TPM header, so I could buy a TPM module. It is not that expensive maybe $20-25 here. So I think it is possible to protect the data and OS from people who can access the hardware. I'll write again when I have an implementation for FreeBSD.
 
[...] Is it possible to run FreeBSD from pen drive? I assume not because it uses ZFS. I guess I really need to read more from the Handbook.
the question has already been answered for stock native FreeBSD. There's also NomadBSD.
On topic: I decided to wait for OpenZFS@FreeBSD to settle, before using native ZFS encryption. GELI seems to have issues on boot now & then (asking for the password, search the forum). IMHO it seems safe to use GELI for an encrypted swap partition, since it does not need to ask for a password. EDIT Looks like these are BIOS issues, and not bugs in GELI. But they are of practical relevance. When I put my GELI encrypted disks into another system (e.g. my laptop dies), there's a chance that I can not access my data.
 
the question has already been answered for stock native FreeBSD. There's also NomadBSD.
On topic: I decided to wait for OpenZFS@FreeBSD to settle, before using native ZFS encryption. GELI seems to have issues on boot now & then (asking for the password, search the forum). IMHO it seems safe to use GELI for an encrypted swap partition, since it does not need to ask for a password.
I don't consider it production ready, but for me it is good enough for my personal projects. So I'll go with ZFS native encryption.
 
pefs(8) (sysutils/pefs-kmod) was not mentioned. Usually it is not needed to encrypt the whole disk, but only some home directories or parts of these instead. Then pefs is perfect. Quote: PEFS is a kernel level stacked cryptographic filesystem for FreeBSD.
Key features:
  • Transparently runs on top of existing file systems
  • Random per file tweak value for encryption
  • Stores metadata only in encrypted file name
  • Arbitrary number of keys per file system, mixing keys in same
    directory and key chains
  • Modern cryptographic algorithms: AES and Camellia in XTS mode,
    PKCS#5v2 and HKDF for key generation.

    WWW: https://github.com/glk/pefs
    WWW: http://wiki.freebsd.org/PEFS
 
Back
Top