I don't think you'd need SSS for the case of two parties where both have to release their key-shares. A plain old one-time pad (XOR with random data) would do.
That's cool. I get by with dracut-sshd for my AlmaLinux hosts with encrypted root partitions, but it's not fully unattended. You still have to log in and type the password yourself. I saw this blog post about getting something similar going with FreeBSD, but I never tried it.
Out of interest, how come the server decrypts the password-half that it keeps using the client-provided key, rather than just sending the encrypted data and letting the client handle the decryption? That way, the server would never touch the key or the raw password-half.
Out of interest, how come the server decrypts the password-half that it keeps using the client-provided key, rather than just sending the encrypted data and letting the client handle the decryption? That way, the server would never touch the key or the raw password-half.
That's a good question. The reason it's this way is because I wanted to protect key retrievals with a password (to prevent arbitrary access, but also to detect malicious retrieval attempts as shown in the dashboard), so the natural thing to do after that password already made it to the server was to reuse it for encryption/decryption of the server-side key. I definitely didn't want to store user keys unencrypted at rest.
As a different option, I could return the encrypted blob to the client, but that'd no better because then the server would still see the password for a moment.
Yet another option would be to have a different password on the client to handle key decryption, but that would adds extra complexity (we'd end up with a password for retrieval, a password for decryption, and a local half) and I'm not seeing much of a gain for that.
Which leads to another completely different option: the "local half" could become the decryption key for the remote blob, instead of gluing together two halves. That would resolve this, but I kinda like the local/remote key separation + recombination that I have now because it's easy to reason about and convince yourself that the local portion was really generated locally and never left the machine.
I'm writing an end-to-end encrypted app right now (for fun), and I solved a similar problem by having the server keep an HKDF-derived hash of the password, to compare against a client-provided hash for authentication.
My flow goes:
Client uses scrypt to derive some bits (D) from their password
Client computes an authentication key A = HKDF(D, "authentication") and an encryption key K = HKDF(D, "encryption")
Client submits A to the server (over HTTPS)
Server compares A with a stored, known value
If successful, server returns encrypted content (C) to client
Client computes Decrypt(K, C) to get the decrypted data.
That way you can use the same password for auth and decryption, but HKDF gives you the guarantee that the server can't get the decryption key from the auth key.
Hi! I'm posting this new article of mine here because I have mentioned my work on ZKeys (not by name) in a bunch of the recent "What are you doing this week/weekend" threads and I finally published the project. There was some very light interest in those threads so this announcement seems suitable.
You'll notice that the use-case for this project is extremely niche, but I'm sure we have a bunch of people running their own NAS with FreeBSD and ZFS around here. Oh, but don't let that put you off: I also have support for Fedora out of the box now, and could add other systems if there is interest in the idea.
Note that you need a coupon to register. The service is free but I just want to gate registrations in case something goes rogue. Use LAUNCH50 and you're in.
At least on Linux, you can set up dropbear to run in the initramfs, so you can ssh in to unlock the disks. Debian has a ready-to-use package for this, and the Gentoo Wiki has a guide for setting it up from scratch which seems like it should work on other distros too.
I wonder if there's a way to keep the encryption key in memory while rebooting, so you wouldn't even have to do that (unless you lose power or something). That'd be pretty cool.
I have been considering trying to set up disk encryption key storage in the TPM, but honestly, I'd prefer to be able to ssh in and enter the passphrase. Usually when I'm putting off rebooting, it's because I don't want to go across the room and get down on my hands and knees to plug the little monitor and keyboard into the server. Entering a passphrase from my laptop across the room would be fine.
Thanks, this is some valuable information I did not know. I just realized, I wouldn't even need that. My boot drive is unencrypted, it's only the disk drives that are encrypted. The boot drive holds no data of importance (swap is disabled).
I don't know if you implemented it, but it would be useful to link the key to a physical location as extra security measure. Bringing up a stolen machine should typically cause it to get a new IP address and "location" (different hops along the route) in the network.
This solves the exact problem I had with my cheap OVH bare metal box that I had parked, thanks! My box doesn't have a TPM and I was considering a similar solution to this but unsure about the direction and the required engineering effort. Great to see validation and the concrete implementation. I may give this a try when I have time to work on it.
jackdk | 16 hours ago
Would Shamir's Secret Sharing be a better fit here, so compromising either half doesn't get you any information?
cyberia | 14 hours ago
I don't think you'd need SSS for the case of two parties where both have to release their key-shares. A plain old one-time pad (XOR with random data) would do.
cyberia | 20 hours ago
That's cool. I get by with dracut-sshd for my AlmaLinux hosts with encrypted root partitions, but it's not fully unattended. You still have to log in and type the password yourself. I saw this blog post about getting something similar going with FreeBSD, but I never tried it.
Out of interest, how come the server decrypts the password-half that it keeps using the client-provided key, rather than just sending the encrypted data and letting the client handle the decryption? That way, the server would never touch the key or the raw password-half.
[OP] jmmv | 16 hours ago
That's a good question. The reason it's this way is because I wanted to protect key retrievals with a password (to prevent arbitrary access, but also to detect malicious retrieval attempts as shown in the dashboard), so the natural thing to do after that password already made it to the server was to reuse it for encryption/decryption of the server-side key. I definitely didn't want to store user keys unencrypted at rest.
As a different option, I could return the encrypted blob to the client, but that'd no better because then the server would still see the password for a moment.
Yet another option would be to have a different password on the client to handle key decryption, but that would adds extra complexity (we'd end up with a password for retrieval, a password for decryption, and a local half) and I'm not seeing much of a gain for that.
Which leads to another completely different option: the "local half" could become the decryption key for the remote blob, instead of gluing together two halves. That would resolve this, but I kinda like the local/remote key separation + recombination that I have now because it's easy to reason about and convince yourself that the local portion was really generated locally and never left the machine.
cyberia | 14 hours ago
Right, that makes sense.
I'm writing an end-to-end encrypted app right now (for fun), and I solved a similar problem by having the server keep an HKDF-derived hash of the password, to compare against a client-provided hash for authentication.
My flow goes:
That way you can use the same password for auth and decryption, but HKDF gives you the guarantee that the server can't get the decryption key from the auth key.
ThinkChaos | 10 hours ago
Dis you look into Clevis that's in the same space? Any particular motivation for not using it?
I don't know if it supports FreeBSD, and having more options is nice!
[OP] jmmv | 23 hours ago
Hi! I'm posting this new article of mine here because I have mentioned my work on ZKeys (not by name) in a bunch of the recent "What are you doing this week/weekend" threads and I finally published the project. There was some very light interest in those threads so this announcement seems suitable.
You'll notice that the use-case for this project is extremely niche, but I'm sure we have a bunch of people running their own NAS with FreeBSD and ZFS around here. Oh, but don't let that put you off: I also have support for Fedora out of the box now, and could add other systems if there is interest in the idea.
Note that you need a coupon to register. The service is free but I just want to gate registrations in case something goes rogue. Use LAUNCH50 and you're in.
m_a_r_k | 2 hours ago
What do you see as the value to this tool vs a tpm?
JulianSildenLanglo | 20 minutes ago
Another option would be to encrypt the files instead of the disks. That way the backup server doesn't need to be able to decrypt anything.
jaredkrinke | 19 hours ago
BenjaminRi | 18 hours ago
No, but I never reboot. If I had that problem, e.g. due to power outages, I would use a pikvm to restore access.
dzwdz | 14 hours ago
At least on Linux, you can set up dropbear to run in the initramfs, so you can ssh in to unlock the disks. Debian has a ready-to-use package for this, and the Gentoo Wiki has a guide for setting it up from scratch which seems like it should work on other distros too.
I wonder if there's a way to keep the encryption key in memory while rebooting, so you wouldn't even have to do that (unless you lose power or something). That'd be pretty cool.
rweir | 3 hours ago
soon, I think: https://lwn.net/Articles/1105117/
gcupc | an hour ago
I have been considering trying to set up disk encryption key storage in the TPM, but honestly, I'd prefer to be able to ssh in and enter the passphrase. Usually when I'm putting off rebooting, it's because I don't want to go across the room and get down on my hands and knees to plug the little monitor and keyboard into the server. Entering a passphrase from my laptop across the room would be fine.
EDIT: Fedora and RHEL support dracut-sshd.
BenjaminRi | 14 hours ago
Thanks, this is some valuable information I did not know. I just realized, I wouldn't even need that. My boot drive is unencrypted, it's only the disk drives that are encrypted. The boot drive holds no data of importance (swap is disabled).
sjamaan | 7 hours ago
I don't know if you implemented it, but it would be useful to link the key to a physical location as extra security measure. Bringing up a stolen machine should typically cause it to get a new IP address and "location" (different hops along the route) in the network.
frontsideair | 5 hours ago
This solves the exact problem I had with my cheap OVH bare metal box that I had parked, thanks! My box doesn't have a TPM and I was considering a similar solution to this but unsure about the direction and the required engineering effort. Great to see validation and the concrete implementation. I may give this a try when I have time to work on it.