Re: Full disk encryption - Verifying/changing passphrase
On Mon, Jul 01, 2024 at 10:30:28PM -0700, patrick keshishian wrote: > 1. How can one verify they remember the passphrase before > rebooting/shutting down? If this is a fresh installation, you'll usually want to reboot and check that everything went smoothly anyway. If you've already lost the passphrase at the end of the install process then at that point you'd need to re-install anyway for a usable system, so rebooting to check that you have the correct passphrase is not really an extra burden. > 2. What is the process (steps) to change/update the passphrase? > > Is the process simply running "bioctl -P sdX"? And entering old and > then new passphrases? Yes.
Full disk encryption - Verifying/changing passphrase
Hello, For the first time I decided to set up full disk encryption on a new drive. Process went smoothly! Anyway, here are two possibly silly questions: 1. How can one verify they remember the passphrase before rebooting/shutting down? 2. What is the process (steps) to change/update the passphrase? Is the process simply running "bioctl -P sdX"? And entering old and then new passphrases? --patrick
Re: disk encryption for remote server
I keep a /crypt noauto partition that I mount manually by passphrase via ssh after the server is booted. And don't keep 'sensitive' info in other partitions... On Mon, May 27, 2024 at 11:57 AM <04-psyche.tot...@icloud.com> wrote: > Thanks all for your thoughts. > > Regarding the remote serial console access, unfortunately, it is not > possible in my case. > I do not have IPMI or something similar :( > > On Mon, 27 May 2024 at 08:17, Manuel Giraud < > manuel_at_ledu-giraud_fr_rmp93abv53d47h_m6783...@icloud.com> wrote: > >> Stefan Kreutz writes: >> >> > Can you access the machine's serial console, maybe redirected over IP? >> >> I concur that a remote serial console access (maybe via a web interface >> serviced by your provider) is your best option here. >> >> I used to do (almost) FDE without console access but here is list of >> drawbacks/requirements: >> >> - It is not really FDE because / was not encrypted >> >> - It required patching /etc/rc with the patch at the end of this >> message >> >> - The "/root/sshd" from this patch is a self-contained sshd >> without the need of any external library. It is *not* a copy >> of /usr/sbin/sshd and you have to compile it yourself (and I >> don't remenber how) >> >> >> Best regards, >> -- >> Manuel Giraud >> >
Re: disk encryption for remote server
Thanks all for your thoughts. Regarding the remote serial console access, unfortunately, it is not possible in my case. I do not have IPMI or something similar :( On Mon, 27 May 2024 at 08:17, Manuel Giraud < manuel_at_ledu-giraud_fr_rmp93abv53d47h_m6783...@icloud.com> wrote: > Stefan Kreutz writes: > > > Can you access the machine's serial console, maybe redirected over IP? > > I concur that a remote serial console access (maybe via a web interface > serviced by your provider) is your best option here. > > I used to do (almost) FDE without console access but here is list of > drawbacks/requirements: > > - It is not really FDE because / was not encrypted > > - It required patching /etc/rc with the patch at the end of this > message > > - The "/root/sshd" from this patch is a self-contained sshd > without the need of any external library. It is *not* a copy > of /usr/sbin/sshd and you have to compile it yourself (and I > don't remenber how) > > > Best regards, > -- > Manuel Giraud >
Re: disk encryption for remote server
Stefan Kreutz writes: > Can you access the machine's serial console, maybe redirected over IP? I concur that a remote serial console access (maybe via a web interface serviced by your provider) is your best option here. I used to do (almost) FDE without console access but here is list of drawbacks/requirements: - It is not really FDE because / was not encrypted - It required patching /etc/rc with the patch at the end of this message - The "/root/sshd" from this patch is a self-contained sshd without the need of any external library. It is *not* a copy of /usr/sbin/sshd and you have to compile it yourself (and I don't remenber how) --- rc.orig Wed Jul 27 15:23:24 2011 +++ /etc/rc Thu Jul 28 15:28:28 2011 @@ -294,8 +294,18 @@ exit 1 ;; 8) - echo "Automatic file system check failed; help!" - exit 1 + echo "Automatic file system check failed; help (from outterspace)!" + ifconfig em0 a.b.c.d netmask 255.255.255.0 + route -qn add default a.b.c.1 + mount -uw / + /root/sshd -De \ + -o PasswordAuthentication=no \ + -o ChallengeResponseAuthentication=no \ + -o UsePrivilegeSeparation=no \ + -o UseDNS=no + mount -ur / + route -qn flush + ifconfig em0 down delete ;; 12) echo "Boot interrupted." Best regards, -- Manuel Giraud
Re: disk encryption for remote server
On Sun, May 26, 2024 at 08:33:59PM +0100, 04-psyche.tot...@icloud.com wrote: Hi everyone, Is there any way to use disk encryption without having physical access to the device? You could use a USB keydisk (make sure you, and your assistant on the remote server, have copious backup(s) of this!) as an encryption device, as per this document: https://www.openbsd.org/faq/faq14.html#softraidFDE Cheers Ampie A few potential ideas: - is there a way to enter the encryption passphrase via ssh? - is there a way to create a non encrypted partition on the same hard drive, where the keydisk would be stored, and automatically used? (For various reasons, an external usb key is not feasible). And yes, I realize this would weaken the security significantly, but I'd still like to know if it's feasible? My guess is that it's not possible, but I wanted to ask to make sure. Cheers, Jake
Re: disk encryption for remote server
On Sun, May 26, 2024 at 08:33:59PM +0100, 04-psyche.tot...@icloud.com wrote: > Is there any way to use disk encryption without having physical access to > the device? Yes, it is possible. But I think you are talking about full disk encryption and want to enter a passphrase at the bootloader prompt. > - is there a way to enter the encryption passphrase via ssh? To enter a passphrase at the boot prompt you need to set up remote access to the console of that device. Depending on the setup you have, this might be easy, difficult or impossible. If that is not an option, one possibility is to do a regular non-encrypted installation and create a softraid crypto volume just for storing specific data. This can then be mounted from a regular ssh session after the kernel has booted. It's also possible to hard-code a passphrase in the bootloader code. We have used this technique for years for local development machines that need to be running the softraid code but are otherwise not storing data that needs to be protected by a passphrase. These two ideas can also be used together.
Re: disk encryption for remote server
Can you access the machine's serial console, maybe redirected over IP? On Sun, May 26, 2024 at 08:33:59PM GMT, 04-psyche.tot...@icloud.com wrote: > Hi everyone, > > Is there any way to use disk encryption without having physical access to the > device? > > A few potential ideas: > - is there a way to enter the encryption passphrase via ssh? > - is there a way to create a non encrypted partition on the same hard drive, > where the keydisk would be stored, and automatically used? (For various > reasons, an external usb key is not feasible). And yes, I realize this would > weaken the security significantly, but I'd still like to know if it's > feasible? > > My guess is that it's not possible, but I wanted to ask to make sure. > > Cheers, > Jake
disk encryption for remote server
Hi everyone, Is there any way to use disk encryption without having physical access to the device? A few potential ideas: - is there a way to enter the encryption passphrase via ssh? - is there a way to create a non encrypted partition on the same hard drive, where the keydisk would be stored, and automatically used? (For various reasons, an external usb key is not feasible). And yes, I realize this would weaken the security significantly, but I'd still like to know if it's feasible? My guess is that it's not possible, but I wanted to ask to make sure. Cheers, Jake
Re: Fwd: Disk encryption cipher
It's about private messages. Kirill A. Korinsky : > I wonder how did you blacklist someone by IP who sents his emails into > maillist? By parsing all Received headers to find some bad IP? Or?
Re: Fwd: Disk encryption cipher
On Wed, 06 Mar 2024 10:40:31 +0100, Daniele B. wrote: > > Initially I blacklisted his ip. Then, understood the music, I started to find > its approaching intriguing.. ;D > I wonder how did you blacklist someone by IP who sents his emails into maillist? By parsing all Received headers to find some bad IP? Or? -- wbr, Kirill
Re: Fwd: Disk encryption cipher
Admitting without psycho guys, heartbreak exchanges, NSA (at least) readers this mailing list is without pepper. However, sometimes also the OT of Jan are interesting. Initially I blacklisted his ip. Then, understood the music, I started to find its approaching intriguing.. ;D -Dan Mar 6, 2024 09:36:19 ofthecentury : > Who's this psycho Jan Stary telling people new to OpenBSD not to use > an appropriate public mailing list for legitimate questions?
Re: Fwd: Disk encryption cipher
On 2024-03-06, ofthecentury wrote: > Who's this psycho Jan Stary telling people new to OpenBSD not to use > an appropriate public mailing list for legitimate questions? Sadly some list members are a bit intolerant of things which are perfectly valid topics for the list. > Stop poluting the list with your bullshit. > > On Mar 06 12:16:26, ofthecent...@gmail.com wrote: >> https://github.com/openbsd/src/blob/master/sys/dev/softraid.c >> Judging by the source code it's aes-512-xts now. So yes that's perfectly ok content for the list. >> Such hard. Very cipher. Hacking can't. NSA oh no. He does have a point here though.
Fwd: Disk encryption cipher
Who's this psycho Jan Stary telling people new to OpenBSD not to use an appropriate public mailing list for legitimate questions? -- Forwarded message - From: Jan Stary Date: Wed, Mar 6, 2024 at 1:26 PM Subject: Re: Disk encryption cipher To: ofthecentury Stop poluting the list with your bullshit. On Mar 06 12:16:26, ofthecent...@gmail.com wrote: > https://github.com/openbsd/src/blob/master/sys/dev/softraid.c > Judging by the source code it's aes-512-xts now. > Such hard. Very cipher. Hacking can't. NSA oh no. > > On Wed, Mar 6, 2024 at 12:02 PM Janne Johansson wrote: > > > > Den ons 6 mars 2024 kl 07:17 skrev ofthecentury : > > > > > > Hi. I cannot find what cipher is used for full > > > disk encryption on OpenBSD. I saw a mention > > > of salting too, but really no specifics on what > > > the encryption algorithm is. Is there somewhere > > > I can read about it? And really, what is the cipher > > > used? > > > > The presentation from 2010: > > > > AsiaBSDCon 2010, Mar 11 - 14, 2010, Tokyo, Japan. > > Marco Peereboom gave talks about softraid -- OpenBSD's virtual HBA, > > with benefits (paper) > > > > says it was AES-256 XTS then at least. > > > > -- > > May the most significant bit of your life be positive. > >
Re: Disk encryption cipher
https://github.com/openbsd/src/blob/master/sys/dev/softraid.c Judging by the source code it's aes-512-xts now. Such hard. Very cipher. Hacking can't. NSA oh no. On Wed, Mar 6, 2024 at 12:02 PM Janne Johansson wrote: > > Den ons 6 mars 2024 kl 07:17 skrev ofthecentury : > > > > Hi. I cannot find what cipher is used for full > > disk encryption on OpenBSD. I saw a mention > > of salting too, but really no specifics on what > > the encryption algorithm is. Is there somewhere > > I can read about it? And really, what is the cipher > > used? > > The presentation from 2010: > > AsiaBSDCon 2010, Mar 11 - 14, 2010, Tokyo, Japan. > Marco Peereboom gave talks about softraid -- OpenBSD's virtual HBA, > with benefits (paper) > > says it was AES-256 XTS then at least. > > -- > May the most significant bit of your life be positive.
Re: Disk encryption cipher
Den ons 6 mars 2024 kl 07:17 skrev ofthecentury : > > Hi. I cannot find what cipher is used for full > disk encryption on OpenBSD. I saw a mention > of salting too, but really no specifics on what > the encryption algorithm is. Is there somewhere > I can read about it? And really, what is the cipher > used? The presentation from 2010: AsiaBSDCon 2010, Mar 11 - 14, 2010, Tokyo, Japan. Marco Peereboom gave talks about softraid -- OpenBSD's virtual HBA, with benefits (paper) says it was AES-256 XTS then at least. -- May the most significant bit of your life be positive.
Disk encryption cipher
Hi. I cannot find what cipher is used for full disk encryption on OpenBSD. I saw a mention of salting too, but really no specifics on what the encryption algorithm is. Is there somewhere I can read about it? And really, what is the cipher used?
Re: host-to-host encryption with iked
Tobias Heider writes: > On October 3, 2023 2:30:54 PM GMT+02:00, "Robert B. Carleton" > wrote: >>Tobias Heider writes: >> >>> On October 3, 2023 1:32:39 AM GMT+02:00, "Robert B. Carleton" >>> wrote: >>>>I'm trying to setup host-to-host encryption using iked with the >>>>following configuration: >>>> >>>>On 10.2.2.10: >>>> >>>>ikev2 passive esp from 10.2.2.10 to 10.2.1.11 srcid 10.2.2.10 >>>> >>>>On 10.2.1.11: >>>> >>>>ikev2 active esp from 10.2.1.11 to 10.2.2.10 srcid 10.2.1.11 >>>> >>>>I exchanged the /etc/iked/local.pub files into /etc/iked/pubkeys/ipv4/ >>>>on each host using the respective IPs as the file names. >>>> >>>>When I start iked, it responds agreeably: >>>> >>>>On 10.2.2.10: >>>> >>>># iked -dv >>>>ikev2 "policy1" passive tunnel esp inet from 10.2.2.10 to 10.2.1.11 local >>>>10.2.2.10 peer 10.2.1.11 ikesa enc aes-128-gcm enc aes-256-gcm prf >>>>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group >>>>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group >>>>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc >>>>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf >>>>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth >>>>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 >>>>group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 >>>>group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn >>>>childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth >>>>hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid >>>>10.2.2.10 lifetime 10800 bytes 4294967296 signature >>>>spi=0xe0fd27448726d995: recv IKE_SA_INIT req 0 peer 10.2.1.11:500 local >>>>10.2.2.10:500, 518 bytes, policy 'policy1' >>>>spi=0xe0fd27448726d995: send IKE_SA_INIT res 0 peer 10.2.1.11:500 local >>>>10.2.2.10:500, 235 bytes >>>>spi=0xe0fd27448726d995: recv IKE_AUTH req 1 peer 10.2.1.11:500 local >>>>10.2.2.10:500, 463 bytes, policy 'policy1' >>>>spi=0xe0fd27448726d995: send IKE_AUTH res 1 peer 10.2.1.11:500 local >>>>10.2.2.10:500, 342 bytes >>>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, >>>>0xd94b3836 (enc aes-128-gcm esn) >>>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: >>>>ESP-10.2.2.10/32=10.2.1.11/32(0) >>>>spi=0xe0fd27448726d995: established peer 10.2.1.11:500[IPV4/10.2.1.11] >>>>local 10.2.2.10:500[IPV4/10.2.2.10] policy 'policy1' as responder (enc >>>>aes-128-gcm group curve25519 prf hmac-sha2-256) >>>> >>>>On 10.2.1.11: >>>> >>>># iked -dv >>>>ikev2 "policy1" active tunnel esp inet from 10.2.1.11 to 10.2.2.10 local >>>>10.2.1.11 peer 10.2.2.10 ikesa enc aes-128-gcm enc aes-256-gcm prf >>>>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group >>>>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group >>>>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc >>>>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf >>>>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth >>>>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 >>>>group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 >>>>group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn >>>>childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth >>>>hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid >>>>10.2.1.11 lifetime 10800 bytes 4294967296 signature >>>>ikev2_init_ike_sa: initiating "policy1" >>>>spi=0xe0fd27448726d995: send IKE_SA_INIT req 0 peer 10.2.2.10:500 local >>>>10.2.1.11:500, 518 bytes >>>>spi=0xe0fd27448726d995: recv IKE_SA_INIT res 0 peer 10.2.2.10:500 local >>>>10.2.1.11:500, 235 bytes, policy 'policy1' >>>>spi=0xe0fd27448726d995: send IKE_AUTH req 1 peer 10.2.2.10:500 local >>>>10.2.1.11:500, 463 bytes >>>>spi=0xe0fd27448726d995
Re: host-to-host encryption with iked
On October 3, 2023 2:30:54 PM GMT+02:00, "Robert B. Carleton" wrote: >Tobias Heider writes: > >> On October 3, 2023 1:32:39 AM GMT+02:00, "Robert B. Carleton" >> wrote: >>>I'm trying to setup host-to-host encryption using iked with the >>>following configuration: >>> >>>On 10.2.2.10: >>> >>>ikev2 passive esp from 10.2.2.10 to 10.2.1.11 srcid 10.2.2.10 >>> >>>On 10.2.1.11: >>> >>>ikev2 active esp from 10.2.1.11 to 10.2.2.10 srcid 10.2.1.11 >>> >>>I exchanged the /etc/iked/local.pub files into /etc/iked/pubkeys/ipv4/ >>>on each host using the respective IPs as the file names. >>> >>>When I start iked, it responds agreeably: >>> >>>On 10.2.2.10: >>> >>># iked -dv >>>ikev2 "policy1" passive tunnel esp inet from 10.2.2.10 to 10.2.1.11 local >>>10.2.2.10 peer 10.2.1.11 ikesa enc aes-128-gcm enc aes-256-gcm prf >>>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group >>>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group >>>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc >>>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf >>>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth >>>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 >>>group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 >>>group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn >>>childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth >>>hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid >>>10.2.2.10 lifetime 10800 bytes 4294967296 signature >>>spi=0xe0fd27448726d995: recv IKE_SA_INIT req 0 peer 10.2.1.11:500 local >>>10.2.2.10:500, 518 bytes, policy 'policy1' >>>spi=0xe0fd27448726d995: send IKE_SA_INIT res 0 peer 10.2.1.11:500 local >>>10.2.2.10:500, 235 bytes >>>spi=0xe0fd27448726d995: recv IKE_AUTH req 1 peer 10.2.1.11:500 local >>>10.2.2.10:500, 463 bytes, policy 'policy1' >>>spi=0xe0fd27448726d995: send IKE_AUTH res 1 peer 10.2.1.11:500 local >>>10.2.2.10:500, 342 bytes >>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, >>>0xd94b3836 (enc aes-128-gcm esn) >>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: >>>ESP-10.2.2.10/32=10.2.1.11/32(0) >>>spi=0xe0fd27448726d995: established peer 10.2.1.11:500[IPV4/10.2.1.11] local >>>10.2.2.10:500[IPV4/10.2.2.10] policy 'policy1' as responder (enc aes-128-gcm >>>group curve25519 prf hmac-sha2-256) >>> >>>On 10.2.1.11: >>> >>># iked -dv >>>ikev2 "policy1" active tunnel esp inet from 10.2.1.11 to 10.2.2.10 local >>>10.2.1.11 peer 10.2.2.10 ikesa enc aes-128-gcm enc aes-256-gcm prf >>>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group >>>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group >>>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc >>>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf >>>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth >>>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 >>>group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 >>>group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn >>>childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth >>>hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid >>>10.2.1.11 lifetime 10800 bytes 4294967296 signature >>>ikev2_init_ike_sa: initiating "policy1" >>>spi=0xe0fd27448726d995: send IKE_SA_INIT req 0 peer 10.2.2.10:500 local >>>10.2.1.11:500, 518 bytes >>>spi=0xe0fd27448726d995: recv IKE_SA_INIT res 0 peer 10.2.2.10:500 local >>>10.2.1.11:500, 235 bytes, policy 'policy1' >>>spi=0xe0fd27448726d995: send IKE_AUTH req 1 peer 10.2.2.10:500 local >>>10.2.1.11:500, 463 bytes >>>spi=0xe0fd27448726d995: recv IKE_AUTH res 1 peer 10.2.2.10:500 local >>>10.2.1.11:500, 342 bytes, policy 'policy1' >>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, >>>0xd94b3836 (enc aes-128-gcm esn) >>>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: >>>ESP
Re: host-to-host encryption with iked
Tobias Heider writes: > On October 3, 2023 1:32:39 AM GMT+02:00, "Robert B. Carleton" > wrote: >>I'm trying to setup host-to-host encryption using iked with the >>following configuration: >> >>On 10.2.2.10: >> >>ikev2 passive esp from 10.2.2.10 to 10.2.1.11 srcid 10.2.2.10 >> >>On 10.2.1.11: >> >>ikev2 active esp from 10.2.1.11 to 10.2.2.10 srcid 10.2.1.11 >> >>I exchanged the /etc/iked/local.pub files into /etc/iked/pubkeys/ipv4/ >>on each host using the respective IPs as the file names. >> >>When I start iked, it responds agreeably: >> >>On 10.2.2.10: >> >># iked -dv >>ikev2 "policy1" passive tunnel esp inet from 10.2.2.10 to 10.2.1.11 local >>10.2.2.10 peer 10.2.1.11 ikesa enc aes-128-gcm enc aes-256-gcm prf >>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group >>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group >>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc >>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf >>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth >>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group >>ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group >>modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa >>enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 >>auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 10.2.2.10 >>lifetime 10800 bytes 4294967296 signature >>spi=0xe0fd27448726d995: recv IKE_SA_INIT req 0 peer 10.2.1.11:500 local >>10.2.2.10:500, 518 bytes, policy 'policy1' >>spi=0xe0fd27448726d995: send IKE_SA_INIT res 0 peer 10.2.1.11:500 local >>10.2.2.10:500, 235 bytes >>spi=0xe0fd27448726d995: recv IKE_AUTH req 1 peer 10.2.1.11:500 local >>10.2.2.10:500, 463 bytes, policy 'policy1' >>spi=0xe0fd27448726d995: send IKE_AUTH res 1 peer 10.2.1.11:500 local >>10.2.2.10:500, 342 bytes >>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, >>0xd94b3836 (enc aes-128-gcm esn) >>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: >>ESP-10.2.2.10/32=10.2.1.11/32(0) >>spi=0xe0fd27448726d995: established peer 10.2.1.11:500[IPV4/10.2.1.11] local >>10.2.2.10:500[IPV4/10.2.2.10] policy 'policy1' as responder (enc aes-128-gcm >>group curve25519 prf hmac-sha2-256) >> >>On 10.2.1.11: >> >># iked -dv >>ikev2 "policy1" active tunnel esp inet from 10.2.1.11 to 10.2.2.10 local >>10.2.1.11 peer 10.2.2.10 ikesa enc aes-128-gcm enc aes-256-gcm prf >>hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group >>curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group >>modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc >>aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf >>hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth >>hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group >>ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group >>modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa >>enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 >>auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 10.2.1.11 >>lifetime 10800 bytes 4294967296 signature >>ikev2_init_ike_sa: initiating "policy1" >>spi=0xe0fd27448726d995: send IKE_SA_INIT req 0 peer 10.2.2.10:500 local >>10.2.1.11:500, 518 bytes >>spi=0xe0fd27448726d995: recv IKE_SA_INIT res 0 peer 10.2.2.10:500 local >>10.2.1.11:500, 235 bytes, policy 'policy1' >>spi=0xe0fd27448726d995: send IKE_AUTH req 1 peer 10.2.2.10:500 local >>10.2.1.11:500, 463 bytes >>spi=0xe0fd27448726d995: recv IKE_AUTH res 1 peer 10.2.2.10:500 local >>10.2.1.11:500, 342 bytes, policy 'policy1' >>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, >>0xd94b3836 (enc aes-128-gcm esn) >>spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: >>ESP-10.2.1.11/32=10.2.2.10/32(0) >>spi=0xe0fd27448726d995: established peer 10.2.2.10:500[IPV4/10.2.2.10] local >>10.2.1.11:500[IPV4/10.2.1.11] policy 'policy1' as initiator (enc aes-128-gcm >>group curve25519 prf hmac-sha2-256) >> >>Here's the output from ipsecctl -sa: >> >>On 10.2.2.10: >> >>FLOWS: >>flow esp in from 10.2.1.11 to 10.2
Re: host-to-host encryption with iked
On October 3, 2023 1:32:39 AM GMT+02:00, "Robert B. Carleton" wrote: >I'm trying to setup host-to-host encryption using iked with the >following configuration: > >On 10.2.2.10: > >ikev2 passive esp from 10.2.2.10 to 10.2.1.11 srcid 10.2.2.10 > >On 10.2.1.11: > >ikev2 active esp from 10.2.1.11 to 10.2.2.10 srcid 10.2.1.11 > >I exchanged the /etc/iked/local.pub files into /etc/iked/pubkeys/ipv4/ >on each host using the respective IPs as the file names. > >When I start iked, it responds agreeably: > >On 10.2.2.10: > ># iked -dv >ikev2 "policy1" passive tunnel esp inet from 10.2.2.10 to 10.2.1.11 local >10.2.2.10 peer 10.2.1.11 ikesa enc aes-128-gcm enc aes-256-gcm prf >hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group >curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group >modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc >aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf >hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth >hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group >ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group >modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa >enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth >hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 10.2.2.10 lifetime >10800 bytes 4294967296 signature >spi=0xe0fd27448726d995: recv IKE_SA_INIT req 0 peer 10.2.1.11:500 local >10.2.2.10:500, 518 bytes, policy 'policy1' >spi=0xe0fd27448726d995: send IKE_SA_INIT res 0 peer 10.2.1.11:500 local >10.2.2.10:500, 235 bytes >spi=0xe0fd27448726d995: recv IKE_AUTH req 1 peer 10.2.1.11:500 local >10.2.2.10:500, 463 bytes, policy 'policy1' >spi=0xe0fd27448726d995: send IKE_AUTH res 1 peer 10.2.1.11:500 local >10.2.2.10:500, 342 bytes >spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, >0xd94b3836 (enc aes-128-gcm esn) >spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: >ESP-10.2.2.10/32=10.2.1.11/32(0) >spi=0xe0fd27448726d995: established peer 10.2.1.11:500[IPV4/10.2.1.11] local >10.2.2.10:500[IPV4/10.2.2.10] policy 'policy1' as responder (enc aes-128-gcm >group curve25519 prf hmac-sha2-256) > >On 10.2.1.11: > ># iked -dv >ikev2 "policy1" active tunnel esp inet from 10.2.1.11 to 10.2.2.10 local >10.2.1.11 peer 10.2.2.10 ikesa enc aes-128-gcm enc aes-256-gcm prf >hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group >curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group >modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc >aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf >hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth >hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group >ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group >modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa >enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth >hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 10.2.1.11 lifetime >10800 bytes 4294967296 signature >ikev2_init_ike_sa: initiating "policy1" >spi=0xe0fd27448726d995: send IKE_SA_INIT req 0 peer 10.2.2.10:500 local >10.2.1.11:500, 518 bytes >spi=0xe0fd27448726d995: recv IKE_SA_INIT res 0 peer 10.2.2.10:500 local >10.2.1.11:500, 235 bytes, policy 'policy1' >spi=0xe0fd27448726d995: send IKE_AUTH req 1 peer 10.2.2.10:500 local >10.2.1.11:500, 463 bytes >spi=0xe0fd27448726d995: recv IKE_AUTH res 1 peer 10.2.2.10:500 local >10.2.1.11:500, 342 bytes, policy 'policy1' >spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, >0xd94b3836 (enc aes-128-gcm esn) >spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: >ESP-10.2.1.11/32=10.2.2.10/32(0) >spi=0xe0fd27448726d995: established peer 10.2.2.10:500[IPV4/10.2.2.10] local >10.2.1.11:500[IPV4/10.2.1.11] policy 'policy1' as initiator (enc aes-128-gcm >group curve25519 prf hmac-sha2-256) > >Here's the output from ipsecctl -sa: > >On 10.2.2.10: > >FLOWS: >flow esp in from 10.2.1.11 to 10.2.2.10 peer 10.2.1.11 srcid IPV4/10.2.2.10 >dstid IPV4/10.2.1.11 type require >flow esp out from 10.2.2.10 to 10.2.1.11 peer 10.2.1.11 srcid IPV4/10.2.2.10 >dstid IPV4/10.2.1.11 type require > >SAD: >esp tunnel from 10.2.2.10 to 10.2.1.11 spi 0x0135c999 enc aes-128-gcm >esp tunnel from 10.2.1.11 to 10.2.2.10 spi 0x8a858058 enc aes-128-gcm > >On 10.2.1.
host-to-host encryption with iked
I'm trying to setup host-to-host encryption using iked with the following configuration: On 10.2.2.10: ikev2 passive esp from 10.2.2.10 to 10.2.1.11 srcid 10.2.2.10 On 10.2.1.11: ikev2 active esp from 10.2.1.11 to 10.2.2.10 srcid 10.2.1.11 I exchanged the /etc/iked/local.pub files into /etc/iked/pubkeys/ipv4/ on each host using the respective IPs as the file names. When I start iked, it responds agreeably: On 10.2.2.10: # iked -dv ikev2 "policy1" passive tunnel esp inet from 10.2.2.10 to 10.2.1.11 local 10.2.2.10 peer 10.2.1.11 ikesa enc aes-128-gcm enc aes-256-gcm prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 10.2.2.10 lifetime 10800 bytes 4294967296 signature spi=0xe0fd27448726d995: recv IKE_SA_INIT req 0 peer 10.2.1.11:500 local 10.2.2.10:500, 518 bytes, policy 'policy1' spi=0xe0fd27448726d995: send IKE_SA_INIT res 0 peer 10.2.1.11:500 local 10.2.2.10:500, 235 bytes spi=0xe0fd27448726d995: recv IKE_AUTH req 1 peer 10.2.1.11:500 local 10.2.2.10:500, 463 bytes, policy 'policy1' spi=0xe0fd27448726d995: send IKE_AUTH res 1 peer 10.2.1.11:500 local 10.2.2.10:500, 342 bytes spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, 0xd94b3836 (enc aes-128-gcm esn) spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: ESP-10.2.2.10/32=10.2.1.11/32(0) spi=0xe0fd27448726d995: established peer 10.2.1.11:500[IPV4/10.2.1.11] local 10.2.2.10:500[IPV4/10.2.2.10] policy 'policy1' as responder (enc aes-128-gcm group curve25519 prf hmac-sha2-256) On 10.2.1.11: # iked -dv ikev2 "policy1" active tunnel esp inet from 10.2.1.11 to 10.2.2.10 local 10.2.1.11 peer 10.2.2.10 ikesa enc aes-128-gcm enc aes-256-gcm prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 ikesa enc aes-256 enc aes-192 enc aes-128 enc 3des prf hmac-sha2-256 prf hmac-sha2-384 prf hmac-sha2-512 prf hmac-sha1 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group curve25519 group ecp521 group ecp384 group ecp256 group modp4096 group modp3072 group modp2048 group modp1536 group modp1024 childsa enc aes-128-gcm enc aes-256-gcm group none esn noesn childsa enc aes-256 enc aes-192 enc aes-128 auth hmac-sha2-256 auth hmac-sha2-384 auth hmac-sha2-512 auth hmac-sha1 group none esn noesn srcid 10.2.1.11 lifetime 10800 bytes 4294967296 signature ikev2_init_ike_sa: initiating "policy1" spi=0xe0fd27448726d995: send IKE_SA_INIT req 0 peer 10.2.2.10:500 local 10.2.1.11:500, 518 bytes spi=0xe0fd27448726d995: recv IKE_SA_INIT res 0 peer 10.2.2.10:500 local 10.2.1.11:500, 235 bytes, policy 'policy1' spi=0xe0fd27448726d995: send IKE_AUTH req 1 peer 10.2.2.10:500 local 10.2.1.11:500, 463 bytes spi=0xe0fd27448726d995: recv IKE_AUTH res 1 peer 10.2.2.10:500 local 10.2.1.11:500, 342 bytes, policy 'policy1' spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded SPIs: 0xa7015208, 0xd94b3836 (enc aes-128-gcm esn) spi=0xe0fd27448726d995: ikev2_childsa_enable: loaded flows: ESP-10.2.1.11/32=10.2.2.10/32(0) spi=0xe0fd27448726d995: established peer 10.2.2.10:500[IPV4/10.2.2.10] local 10.2.1.11:500[IPV4/10.2.1.11] policy 'policy1' as initiator (enc aes-128-gcm group curve25519 prf hmac-sha2-256) Here's the output from ipsecctl -sa: On 10.2.2.10: FLOWS: flow esp in from 10.2.1.11 to 10.2.2.10 peer 10.2.1.11 srcid IPV4/10.2.2.10 dstid IPV4/10.2.1.11 type require flow esp out from 10.2.2.10 to 10.2.1.11 peer 10.2.1.11 srcid IPV4/10.2.2.10 dstid IPV4/10.2.1.11 type require SAD: esp tunnel from 10.2.2.10 to 10.2.1.11 spi 0x0135c999 enc aes-128-gcm esp tunnel from 10.2.1.11 to 10.2.2.10 spi 0x8a858058 enc aes-128-gcm On 10.2.1.11: FLOWS: flow esp in from 10.2.2.10 to 10.2.1.11 peer 10.2.2.10 srcid IPV4/10.2.1.11 dstid IPV4/10.2.2.10 type require flow esp out from 10.2.1.11 to 10.2.2.10 peer 10.2.2.10 srcid IPV4/10.2.1.11 dstid IPV4/10.2.2.10 type require SAD: esp tunnel from 10.2.2.10 to 10.2.1.11 spi 0x0135c999 enc aes-128-gcm esp tunnel from 10.2.1.11 to 10.2.2.10 spi 0x8a858058 enc aes-128-gcm Once I try pinging between the hosts, I can still see ICMP traffic on the subject in
autoinstall with full disk encryption
Hello, I was able to auto-install OpenBSD/amd64 except full disk encryption (FDE). Is FDE supported in autoinstall? Thanks much! Boj
Re: Asymmetric file encryption… use gnupg from ports or is there something else?
On Wed, May 10, 2023 at 01:41:47PM +1000, Stuart Longland wrote: > delivery. I've certainly coaxed Taylor UUCP to work over SSH in the > past, and it does work just fine. Not sure if OpenBSD has a built-in > UUCP, but that is an option. It'd solve my immediate problem… but I > figure if they're going to sit there any length of time, I might as > well protect them from prying eyes if possible. > > The aim here is not to defend against every possible attack, it's to > defend against the most probable ones and keep people honest. Mail is most likely leaking while in transit or sitting on servers you have no control over. So putting lots of effort into protecting mail on your backup MX might not make much of a difference in practice. softraid CRYPTO or RAID1C works well for servers. It doesn't protect files if someone gains access to the live system, or gains access to decrypted blocks or volume key in VM memory space if you're running in a VM. But at least the underlying disks or disk images will be unreadable. In a VM in particular it's difficult to reliably protect data from the host system so you'll have to trust the host. You need a way to enter a passphrase at boot so this requires bootloader access on the console. And a reboot happening for any reason requires manual intervention. I am fine with those restrictions and it's been worksing well for me on servers I run. In any case, you could as well encrypt invididual files to make them unreadable to people who manage to peek into the decrypted softraid volume somehow. For invidiual files I cannot think of tools that do this and have great UIs. Maybe indeed try to script something around gnupg or perhaps openssl(1). No good options come to mind... Or accept that you'll have to use a volume to be somehow unlocked/locked on demand and take a look at the security/encfs and security/veracrypt ports, and vnconfig(8) -K. Nesting softraid volumes should be avoided.
Re: Asymmetric file encryption… use gnupg from ports or is there something else?
On Tue, 9 May 2023 13:36:07 -0600 Zack Newman wrote: > Personally, I don't think this makes all that much sense. E-mail is not > very secure. If you can't guarantee communication is E2EE, then this seems > like false security/privacy to me. Not only does the other recipient > likely use a service like Gmail which means your communication is in > Google's hands; but unless you strictly enforce encryption in transit- > most MTAs only use _opportunistic_ encryption-every device your e-mail > traversed possibly has access to the content as well. This is why > applications like Signal are gaining popularity especially in the > crypto/infosec crowd. Well, this is true… for the ultimate guarantee, you use end-to-end encryption tools like S/MIME and OpenPGP. This is a more "can it be done" exercise. If it proves to "not be that secure", then so be it. It's a case of nothing ventured, nothing gained. > Last, if you are worried about the "remote server"; then why not just > host the MTA at your house along with your "home mail server"? If you check the MX records of my present email domain, you'll see that's exactly what I'm doing. The email is hosted at my house (on a Linux VM) behind an OpenBSD router/firewall which is directly connected to this country's glorious NBN. Now, those who know anything about Australia's NBN will know that it is utterly useless in a power outage and can have bouts of unreliability. (I run HFC NBN. NTD is on back-up 12V power, but the infrastructure in the street is not, so in a black-out, the NTD sits there blinking useless asking: "where's my network?!?!") If the NBN goes down, or I'm doing maintenance… MX is down and out. If I'm away from home when it goes down, it might be days before I can get back there to fix it. I'd like my emails to just safely sit somewhere under my control until they can be collected. I could just store them on the server clear-text and use UUCP for delivery. I've certainly coaxed Taylor UUCP to work over SSH in the past, and it does work just fine. Not sure if OpenBSD has a built-in UUCP, but that is an option. It'd solve my immediate problem… but I figure if they're going to sit there any length of time, I might as well protect them from prying eyes if possible. The aim here is not to defend against every possible attack, it's to defend against the most probable ones and keep people honest. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Asymmetric file encryption… use gnupg from ports or is there something else?
On 2023-05-09, Stuart Henderson wrote: Ed25519 is used for signing not encrypting. But Ed25519 keys can be converted and used for encryption; "age" has convenience support for doing this with Ed25519 ssh keys, and might generally be something that works for your use case. It's not in base though. https://words.filippo.io/using-ed25519-keys-for-encryption/ Another possibility is libsodium's crypto_box API but will need more self-assembly as afaik there's no standard CLI tool using this. That doesn't meet their requirements. They want to avoid storing any private key material on the "remote server", and Diffie-Hellman (which is what X25519 is based on) requires access to the private key. Personally, I don't think this makes all that much sense. E-mail is not very secure. If you can't guarantee communication is E2EE, then this seems like false security/privacy to me. Not only does the other recipient likely use a service like Gmail which means your communication is in Google's hands; but unless you strictly enforce encryption in transit- most MTAs only use _opportunistic_ encryption-every device your e-mail traversed possibly has access to the content as well. This is why applications like Signal are gaining popularity especially in the crypto/infosec crowd. Last, if you are worried about the "remote server"; then why not just host the MTA at your house along with your "home mail server"? Simply configure the "remote server" to be a router that routes traffic through a WireGuard tunnel to your house. Then your e-mails will be "at rest" at your house. As an added benefit, you can route local traffic destined to your MTA to be routed directly to your server and avoid the traffic from ever leaving your house. Zack
Re: Asymmetric file encryption… use gnupg from ports or is there something else?
On 2023-05-08, Stuart Longland wrote: > Silly question… is there a tool for encrypting files with asymmetric > keys on OpenBSD? I'm aware of GnuPG in ports, and I'm fine with using > that, however I'm curious to know what other options there are out > there, especially options that are part of the base system. > > I know OpenSSL (and likely LibreSSL) can do RSA for this purpose, > although its CLI is more of a debugging tool than an actual encryption > tool. to be fair, gpg's CLI seems more like a debugging tool too ;) >I'd also like to use ECC keys (ideally ED25519) for future > proofing, since RSA is getting quite long in the tooth now. Ed25519 is used for signing not encrypting. But Ed25519 keys can be converted and used for encryption; "age" has convenience support for doing this with Ed25519 ssh keys, and might generally be something that works for your use case. It's not in base though. https://words.filippo.io/using-ed25519-keys-for-encryption/ Another possibility is libsodium's crypto_box API but will need more self-assembly as afaik there's no standard CLI tool using this.
Re: Asymmetric file encryption… use gnupg from ports or is there something else?
On Tue, May 09, 2023 at 09:21:03AM +1000, Stuart Longland wrote: > Hi all, > > Silly question… is there a tool for encrypting files with asymmetric > keys on OpenBSD? I'm aware of GnuPG in ports, and I'm fine with using > that, however I'm curious to know what other options there are out > there, especially options that are part of the base system. You may want to take a look at enchive (http://nullprogram.com/blog/2017/03/12/) It's not in base, but it's self-contained and tiny.
Asymmetric file encryption… use gnupg from ports or is there something else?
Hi all, Silly question… is there a tool for encrypting files with asymmetric keys on OpenBSD? I'm aware of GnuPG in ports, and I'm fine with using that, however I'm curious to know what other options there are out there, especially options that are part of the base system. I know OpenSSL (and likely LibreSSL) can do RSA for this purpose, although its CLI is more of a debugging tool than an actual encryption tool. I'd also like to use ECC keys (ideally ED25519) for future proofing, since RSA is getting quite long in the tooth now. The use case here is to make an encrypted inbound mail queue: I'll be setting up OpenSMTPD to deliver emails through a script which will encrypt the emails with a public key so they can be collected over SFTP by my home mail server for final delivery. Basically like UUCP of yesteryear, but implemented with OpenSSH. The thinking being that while the emails are "at rest" on the remote server, they're stored encrypted, and apart from maybe destination host details (the destination user is the remote server's problem and can be stored encrypted), there's nothing kept on that remote server in the way of key material that would enable disclosure of the email content -- an attacker would have to catch such emails as they're being received (or compromise host binaries to leak content). This is experimental, done for intellectual curiosity rather than for any real necessity, but you never know… might come in handy. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: Reinstalling kernel with full disk encryption
I fixed it by booting into snapshots install72.img (-stable kernel turns out to not boot -current) and going thorugh the upgrade process. installboot must've been what I needed to do. For the sake of the archive: Initially I couldn't upgrade because I exited to shell from the installer to decrypt the disk right at the prompt asking which disk to upgrade, and the installer didn't recognize the disk at that point. I had to exit at the keyboard layout prompt right beforehand to have it recognized. Thank you for the help. On December 29, 2022 10:00:30 AM UTC, Crystal Kolipe wrote: >On Wed, Dec 28, 2022 at 09:01:26PM +, Chris wrote: >> After that however, the bootloader no longer prompts me for the full disk >> encryption passphrase. Previously it was prompting me for the FDE passphrase >> before it tried to boot the broken kernel. > >I'm assuming that you only have a single disk in this machine, and that you >are not multi-booting with another OS. If this is not the case, let us know. > >Does the machine actually boot in to your old system now if you do: > >boot sr0a:/bsd > >at the boot prompt? > >Or does the kernel boot, but complain that it cannot find the root volume? > >If the machine does boot, you probably just need to run: > ># installboot -v sd1
Re: Reinstalling kernel with full disk encryption
On Wed, Dec 28, 2022 at 09:01:26PM +, Chris wrote: > After that however, the bootloader no longer prompts me for the full disk > encryption passphrase. Previously it was prompting me for the FDE passphrase > before it tried to boot the broken kernel. I'm assuming that you only have a single disk in this machine, and that you are not multi-booting with another OS. If this is not the case, let us know. Does the machine actually boot in to your old system now if you do: boot sr0a:/bsd at the boot prompt? Or does the kernel boot, but complain that it cannot find the root volume? If the machine does boot, you probably just need to run: # installboot -v sd1
Reinstalling kernel with full disk encryption
Hello misc, I tried to stop a sysupgrade before it updated anything by pressing the power button, but by the time the computer shut off the install script was already midway through updating the kernel. I know, bad idea on my part. I was left with an unbootable kernel. To repair it I booted into install72.img, decrypted the disk and copied over the 7.2 kernel from sets. The machine was running -current but I assume the 7.2 kernel would boot it as well. After that however, the bootloader no longer prompts me for the full disk encryption passphrase. Previously it was prompting me for the FDE passphrase before it tried to boot the broken kernel. How to fix this? Help would be much appreciated.
Re: dual boot with full disk encryption for OpenBSD
On Mon, Dec 5, 2022, at 12:26 PM, Mare Dedeu wrote: > Hi, > > I recently had to fight with a thinkpad l13 gen 3 to install OpenBSD with > full disk encryption alongside with linux for blobs like zoom etc. I hope > somebody else can profit from the effort. It is trivial, I guess, but it > might be helpful for someone. > > https://astro-gr.org/openbsd-full-encryption-with-dual-boot/ > > Cheers Mare, This guide is very helpful! Kevin
dual boot with full disk encryption for OpenBSD
Hi, I recently had to fight with a thinkpad l13 gen 3 to install OpenBSD with full disk encryption alongside with linux for blobs like zoom etc. I hope somebody else can profit from the effort. It is trivial, I guess, but it might be helpful for someone. https://astro-gr.org/openbsd-full-encryption-with-dual-boot/ Cheers
Re: full disk encryption with keydisk
On Wed, Dec 29, 2021 at 05:22:19PM -0500, openbsd-m...@pyr3x.com wrote: > Hello, > > I'm using full disk encryption via the softraid subsystem and bioctl with a > keydisk. I have a second drive that I'm backing up the root filesystem to > via ROOTBACKUP=1 and the proper fstab entry. > > I'd like to be able to reuse the same keydisk to decrypt the second drive. > It appears there is no way to inform bioctl to reuse a correctly formatted > keydisk, so it overwrites it each time. Right now I've opted to use a > passfile for the second drive and confirmed I could boot to it by entering > the passphrase via 'boot sr1a:/bsd -a' -- but I'd prefer to simply let it > pickup the keydisk. Is there something I'm missing? Two different crypto volumes cannot use the same RAID type disklabel slice as a keydisk. However, you can create two distinct RAID type disklabel slices on your key disk device (1MB per slice should be sufficient), and then pass one of each of those slices to bioctl -k when you create your two crypto volumes. This way, a single physical disk device will be able to unlock both volumes.
bioctl -cC -l /dev/sd1a softraid0 for encryption two disks RAID1 mirrored
Hi misc, I'd like to have two encrypted 1TB disks in RAID 1 mirror mode (no hardware RAID installed). Is it possible to use bioctl for that purpose or do I need to use HW RAID and encrypt mirrored disks with bioctl -cC -l /dev/sd1a softraid0 ? Please advice. Martin
Re: bioctl -cC -l /dev/sd1a softraid0 for encryption two disks RAID1 mirrored
On Mon, Oct 19, 2020 at 06:28:50PM +, Martin wrote: > I'd like to have two encrypted 1TB disks in RAID 1 mirror mode (no hardware > RAID installed). Is it possible to use bioctl for that purpose or do I need > to use HW RAID and encrypt mirrored disks with bioctl -cC -l /dev/sd1a > softraid0 ? > Please advice. Yes, it's possible, and quite common I guess. OpenBSD cannot boot from an encrypted softraid(4) RAID 1+CRYPTO though, so true RAID 1+CRYPTO FDE is not achieveable. (You'll have to leave an unencrypted partition for root so that the system can boot into singleuser. When not finding the remaining of fstab(5) mounts, rc(8) will complain and stop and give you the option to drop to a prompt where you can manually bioctl(8) the CRYPTO partition before continue booting. Kinda cumbersome since every (re)boot will have to be performed attended, so you should carefully consider whether your data is truly so important as to justify the added troubles.) Cheers, Erling
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
What would you suggest to keep private key material in a safe place? There are rumors that even material stored as not extractable in Nitrokey Pro still can be extracted by side channels like electromagnetic emission. Would running all Internet communication end points on low powered Cortex A7 (immune to Spectre) single boards with a NitroKey like device help? May be need to add optical convertors here to avoid a long Ethernet antenna? Can Nitrokey Pro be used to keep SSHD private key on a server running OpenBSD? On Linux it seems to be possible: https://support.nitrokey.com/t/can-nitrokey-pro2-be-used-in-openbsd-with-ssh-and-gpg/2347/16 Please confirm if Nitrokey Pro can be used on OpenBSD current or 6.7 for keeping both client and server private keys ?
Full disk encryption FAQ update request
We had a VPS customer ask for help on full disk encryption, and since following the instructions on https://www.openbsd.org/faq/faq14.html#softraidFDE did not work with a serial console, we published a blog post on it: https://prgmr.com/blog/openbsd/2020/05/08/openbsd-encrypted-root.html I don't know how to submit a patch to the related FAQ entry, and the footer on https://www.openbsd.org/faq/index.html says to email here with comments. Can the information on the serial console + encrypted root be added to the FAQ please? Regards, Sarah
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
Some time ago Google bought 2000qbit version from D-wave and confirmed it is a quantum computer bla bla bla... but cluster consists of eight qbit blocks to build advertised capacity if I understand googles papers right. My question was about decrypting currently generated and accumulated encrypted traffic after five - ten years on quantim computers if they were available. And which crypto algo. I have to use right now to prevent decryption in post quantum computing era. Martin ‐‐‐ Original Message ‐‐‐ On Saturday, May 9, 2020 2:34 PM, wrote: > D-waves has too uncoupled qubits if I understand it correctly, it is nothing > to do about qubits quantity as we used to think about it. Like a "cluster" of > completely isolated hosts (which is already not a cluster or course).
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On Sat, May 9, 2020 at 1:05 PM Kevin Chadwick wrote: > Careful of what sources you trust! If a processor was storing the keys used, > non > volatile then people would have found out. Software encryption wouldn't save > you > either. If there is a back door it won't have anything to do with AES-NI that > can be analysed so easily. Indeed -- human based key compromise issues severely outweigh the risk of direct attacks on a tcp session with encrypted content. That said, the risk with encrypted material here is not attacks on individual sessions but opportunistic attacks on large bodies of sample material (with, of course, human assist which will often have economic basis and vectors). (That said, I would also keep in mind also that supposedly the computer industry has hit a performance wall because of Moore's Law issues. But, assuming that there's a thread of truth in the marketing, we also have reason to believe that 5G switches at speeds an order of magnitude faster than anything we see on computer busses. So it's not just about the size of the transistors. And, sure, there's real issues there, but I think we have to assume that some of what we're hearing about computational abilities and limits isn't completely factual.) Thanks, -- Raul
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 16:25, i...@aulix.com wrote: > Note: Since these MS / U.S. government keys are deeply sticking in Intel XEON > processor hardware, it doesn’t play a role, what other OS you install or boot > afterwards: Debian/UBUNTU Linux, OpenBSD, … If your software uses Intel > AES-NI hardware encryption, all encrypted packets ingoing, outgoing - then > automatically contain that U.S. government backdoor! Careful of what sources you trust! If a processor was storing the keys used, non volatile then people would have found out. Software encryption wouldn't save you either. If there is a back door it won't have anything to do with AES-NI that can be analysed so easily. I'm conscious of being far from OpenBSD relevance, so excluding myself from this thread now.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
Though I am a very noob in understanding crypto from a mathematical point of view (not just as an user of some ready program) IMHO following message can contain some truth about insecurity and intentional flaws of hardware crypto in X86 CPUs: https://support.nitrokey.com/t/spectre-or-meltdown-vulnerability/850 https://archive.fo/bF0gg Note: Since these MS / U.S. government keys are deeply sticking in Intel XEON processor hardware, it doesn’t play a role, what other OS you install or boot afterwards: Debian/UBUNTU Linux, OpenBSD, … If your software uses Intel AES-NI hardware encryption, all encrypted packets ingoing, outgoing - then automatically contain that U.S. government backdoor!
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 14:34, i...@aulix.com wrote: > D-waves has too uncoupled qubits if I understand it correctly, it is nothing > to do about qubits quantity as we used to think about it. Like a "cluster" of > completely isolated hosts (which is already not a cluster or course). I don't care for the details. D-waves tech has no hope of breaking any crypto in use today is what I have heard from reputable sources. Googles needs to go from 53 to an estimated more than 3000 for nistp-521 with each one being exponentially harder to manage. RSA 8192/4096 are the next best options but RSA takes exponentially longer to generate larger keys. Don't worry. The work is to be ready in case someone with enough funds makes a breakthrough. There is almost zero chance for many many years. You can always mix in a static symmetric key, if really needed or encrypt the data first with a static key? Wireguard offers mixing in a static key as an optional extra config option but wireguard has chosen not to support AES, so will be a lot slower on many modern processors and microchips that have AES hw support. The wireguard author seems to think the opposite about micro support, but he is wrong.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 14:31, i...@aulix.com wrote: > guessed by quantum provided session symmetric cipher is strong enough? Quantum does not break any in use today and AES-256 symmetric is expected to be quantum resistant in any case. I personally prefer AES-256 ctr over the more complex GCM. I am not a developer btw.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
D-waves has too uncoupled qubits if I understand it correctly, it is nothing to do about qubits quantity as we used to think about it. Like a "cluster" of completely isolated hosts (which is already not a cluster or course).
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
OpenSSH allows to use hybrid mode with many private keys of different type and even stored on different hardware like Nitrokey, Rutoken, etc. at the same time for a single session. E.g. 4 different private keys are required (say Nitrokey, Rutoken ECP2, Curve25519 and Postquantum one): AuthenicationMethods=publickey,publickey,publickey,publickey Will it prevent session analysis if only some part of keys (not all) were leaked or guessed by quantum provided session symmetric cipher is strong enough?
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
This one https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html is the most powerful 5000qbits quantum computer sells nowadays. Moreother, D-Wave opened online service to access 5000qbit remotely for solving 'special' tasks which can be accelerated using quantum architecture. In 2016 Google tested some encryption sub-layer in Chrome browser to test quantum resistant encryption algo. According to current online data collecting practices, after six years most of 'old' algorithms will possible to decrypt directly from storage by 'modern' quantum computers. Martin ‐‐‐ Original Message ‐‐‐ On Saturday, May 9, 2020 5:05 AM, wrote: > According to Damien Miller: > > > this is pretty much possible now, by enabling the experimental support > > for the XMSS PQ signature algorithm > > in the SSH
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 07:41, Martin wrote: > This one > https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html > is the most powerful 5000qbits quantum computer sells nowadays. D-waves definition of qubit is different and their machines will never be capable of breaking public key cryptography using Shor's algorithm. I assume they want free publicity that you are giving them.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 2020-05-09 07:41, Martin wrote: > This one > https://www.tomshardware.com/news/d-wave-5000-qubit-first-sale,40470.html > is the most powerful 5000qbits quantum computer sells nowadays. > > Moreother, D-Wave opened online service to access 5000qbit remotely for > solving 'special' tasks which can be accelerated using quantum architecture. > > In 2016 Google tested some encryption sub-layer in Chrome browser to test > quantum resistant encryption algo. > > According to current online data collecting practices, after six years most > of 'old' algorithms will possible to decrypt directly from storage by > 'modern' quantum computers. That last sentence doesn't even make sense but is completely wrong. Decrypt according to? No Googles computer was an impressive jump to 53 qubits but every qubit is exponentially harder to keep stable. The pqcrypto project estimated far longer before an algorithm is broken by a computer and even then I believe they are talking about weaker keys. Not in our lifetime is often mentioned. It is quite possible and in my opinion probable that a nistp-521 key will never be broken by a quantum computer. I assume this is coming from the recent release of code by the PQCrypto project for OpenSSL. The PQCrypto project hasn't concluded yet. You should not use it yet especially without existing crypto too. There are some conservative algorithms that may not win the competition that are arguably useable under certain conditions but that is aside from the point. The one OpenSSH has developed is one of those.
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
On 5/8/20 3:16 PM, Martin wrote: > Which 'quantum' resistant algorithms can be used right now to prevent data > decryption in future by 'quantum' computers (when they can do this) of > currently collected data flows? this is so dumb. worry about this when there are computers which can actually add two numbers quantoonly. aisha > > Martin >
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
According to Damien Miller: >this is pretty much possible now, by enabling the experimental support for the XMSS PQ signature algorithm in the SSH
Re: 'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
https://www.technologyreview.com/2018/02/21/145300/serious-quantum-computers-are-finally-here-what-are-we-going-to-do-with-them/ https://www.microsoft.com/en-us/research/project/post-quantum-ssh/ https://openquantumsafe.org/ Why not to add post quantum algos to the SSH mainline to make them easily available at once in all up to date distros?
'post quantum' encryption algorithm(s) in latest libressl and upcoming 6.7 to chose
Which 'quantum' resistant algorithms can be used right now to prevent data decryption in future by 'quantum' computers (when they can do this) of currently collected data flows? Martin
Re: Full disk encryption including /boot, excluding bootloader?
On Tue, Feb 18, 2020 at 08:05:29AM +0100, Paul de Weerd wrote: On Tue, Feb 18, 2020 at 05:12:25AM +, Frank Beuth wrote: | Yes, it's a cool way to combine things to get unexpected functionality. | I haven't dug into the bootloader much... is there a reasonably easy way | to get the USB-stick-bootloader to boot the hard drive partition by | default? Best way to dig into the bootloader is by starting at its fine manpage which you can read online at http://man.openbsd.org/man8/amd64/boot.8 The quick answer is `echo 'boot sr0a:/bsd' > /etc/boot.conf` (on the USB-stick's root filesystem). Thanks!
Re: Full disk encryption including /boot, excluding bootloader?
> Are there any downsides though? For example, would resume from > hibernation still work for such a setup? It should work with hibernation without any problems, but i did not test this extensively. > > More so, for the less knowledgeable of us, how does this relate to > UEFI's "Secure Boot"? I can only hope OpenBSD will support it some > day, at least for amd64. Debian has implemented it for the last major > release, Debian 10. Secure Boot as defined by the UEFI specification works with cryptographic signatures instead of just measuring. Meaning there is also a Chain in which every component has to verify the Signature of the next one. The downside of this approach is, that in order to verify any signature, you need some keys that you trust. If your name is Microsoft, than you can get every vendor to include your keys inside the firmware and your bootloader can be verified. This is obviously very convenient for the user. If you are not Microsoft and your signature key is not included in the firmware, than users have to sign the boot components manually and add their keys to the firmware. To sum it up. I think that SecureBoot was the right choice for Microsoft but for FOSS the TPM approach is less hassle for the user. Also measuring can not only be done for the executable itself, but also for the data it uses. That way buffer overflow attacks can also be detected. The signature based approach can not do that. In the next few days i will write a email to misc containing a small manual and all the source code. Best Regards Julius
Re: Full disk encryption including /boot, excluding bootloader?
Make sure no one has physical access to you machine! EVER. Lock it away. That way no 'Evil Maid' or any one else can access it! This is not hard. Why is this a thing? If someone has physical access to you box then it is Game Over! All of these fantasy efforts are BS. Physically secure your hardware people! You are deluding yourselves.
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 04:09:57PM +0100, Julius Zint wrote: I'm not really in a position to reflash my machine but I would still be curious for details. There is no need to reflash your firmware if the system has a integrated and supported TPM 1.2 chip. The prototype uses a Static Root of Trust for Measurment (SRTM) approach where the Chain of Trust is extended from a small immutable firmware part up to boot(8). Every component in the boot chain is responsible for measuring the components, that it hands control over the system. Measuring just means calculating the hash and sending it to the TPM. The following example is the Chain of Trust from my test system Lenovo Thinkpad X240 with OpenBSD. 1: Core Static Root of Trust for Measurment (C-SRTM) (immutable part of the Firmware) 2: Firmware (including OptionROMS) 3: MBR (mbr(8)) 4: PBR (biosboot(8)) 5: boot(8) (residing in the softraid(4) metadata when FDE is enabled) I changed the mbr(8) and biosboot(8) to support measuring their next component. Because there is very little available space left in the 440 byte of the mbr(8) startprogram, you have to choose between CHS and measurement support at compile time. boot(8) got support via a machine specific command to seal and unseal a secret of your choosing to any drive. Sealing and unsealing means encrypting/decrypting data depending on the state of the Platform Control Registers (PCR). PCRs are in the TPM NVRAM and store the measurements. With the laptop being in a trusted state, you can seal a secret and store it on a usb drive. When you want to verify, that the software components are unchanged, you plug in the usb drive and unseal the secret. If the output shows the correct secret and you were the only person knowing it, than there is a very high chance that the early boot components are unchanged. Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? That sounds awesome! Hope you are working on upstreaming your changes. Are there any downsides though? For example, would resume from hibernation still work for such a setup? More so, for the less knowledgeable of us, how does this relate to UEFI's "Secure Boot"? I can only hope OpenBSD will support it some day, at least for amd64. Debian has implemented it for the last major release, Debian 10. Thanks!
Re: Full disk encryption including /boot, excluding bootloader?
On Tue, Feb 18, 2020 at 05:12:25AM +, Frank Beuth wrote: | Yes, it's a cool way to combine things to get unexpected functionality. | I haven't dug into the bootloader much... is there a reasonably easy way | to get the USB-stick-bootloader to boot the hard drive partition by | default? Best way to dig into the bootloader is by starting at its fine manpage which you can read online at http://man.openbsd.org/man8/amd64/boot.8 The quick answer is `echo 'boot sr0a:/bsd' > /etc/boot.conf` (on the USB-stick's root filesystem). Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 06:44:25PM +0100, Paul de Weerd wrote: On Mon, Feb 17, 2020 at 01:35:38PM +, Frank Beuth wrote: | > | This way the evil maid would have nothing to tamper with. | > | > Note that with this approach, a default OpenBSD install to your | > machine will still install a bootloader on the physical disk inside | > your machine. It's then on you to NOT use that. | | That's a heck of a hack! Not sure how you mean that - I don't think it's that much of a hack, mostly an interesting side-effect of how the bootloader works in general. Taken in combination with a "normal" install to removable media, you get basically exactly what you want at no additional cost. Note that you don't have to do a full (or even minimal) install, if all you really want is use the bootloader on the removable media. It's just the easiest way to prepare it that I know of. Besides, if you do a 'normal' install, you have a convenient 'live' or 'rescue' system to carry around with you whenever you go: I've got one of these on my keychain :) Yes, it's a cool way to combine things to get unexpected functionality. I haven't dug into the bootloader much... is there a reasonably easy way to get the USB-stick-bootloader to boot the hard drive partition by default?
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 04:09:57PM +0100, Julius Zint wrote: I'm not really in a position to reflash my machine but I would still be curious for details. There is no need to reflash your firmware if the system has a integrated and supported TPM 1.2 chip. The prototype uses a Static Root of Trust for Measurment (SRTM) approach where the Chain of Trust is extended from a small immutable firmware part up to boot(8). Every component in the boot chain is responsible for measuring the components, that it hands control over the system. Measuring just means calculating the hash and sending it to the TPM. The following example is the Chain of Trust from my test system Lenovo Thinkpad X240 with OpenBSD. 1: Core Static Root of Trust for Measurment (C-SRTM) (immutable part of the Firmware) 2: Firmware (including OptionROMS) 3: MBR (mbr(8)) 4: PBR (biosboot(8)) 5: boot(8) (residing in the softraid(4) metadata when FDE is enabled) I changed the mbr(8) and biosboot(8) to support measuring their next component. Because there is very little available space left in the 440 byte of the mbr(8) startprogram, you have to choose between CHS and measurement support at compile time. boot(8) got support via a machine specific command to seal and unseal a secret of your choosing to any drive. Sealing and unsealing means encrypting/decrypting data depending on the state of the Platform Control Registers (PCR). PCRs are in the TPM NVRAM and store the measurements. With the laptop being in a trusted state, you can seal a secret and store it on a usb drive. When you want to verify, that the software components are unchanged, you plug in the usb drive and unseal the secret. If the output shows the correct secret and you were the only person knowing it, than there is a very high chance that the early boot components are unchanged. Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? That's amazing if you can get it to work without reflashing. Are you then sealing the disk encryption key? Unfortunately I have to be a bit conservative with my laptop, but I would be quite interested in testing this once it's near-production-ready.
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 01:35:38PM +, Frank Beuth wrote: | > | This way the evil maid would have nothing to tamper with. | > | > Note that with this approach, a default OpenBSD install to your | > machine will still install a bootloader on the physical disk inside | > your machine. It's then on you to NOT use that. | | That's a heck of a hack! Not sure how you mean that - I don't think it's that much of a hack, mostly an interesting side-effect of how the bootloader works in general. Taken in combination with a "normal" install to removable media, you get basically exactly what you want at no additional cost. Note that you don't have to do a full (or even minimal) install, if all you really want is use the bootloader on the removable media. It's just the easiest way to prepare it that I know of. Besides, if you do a 'normal' install, you have a convenient 'live' or 'rescue' system to carry around with you whenever you go: I've got one of these on my keychain :) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Full disk encryption including /boot, excluding bootloader?
I’m interested as well. Jan On 17 Feb 2020, at 17:10, Kevin Chadwick wrote: On 2020-02-17 15:09, Julius Zint wrote: Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? I'm interested
Re: Full disk encryption including /boot, excluding bootloader?
On 2020-02-17 15:09, Julius Zint wrote: > Some feedback from the OpenBSD community on this would also be appreciated. > Are there > enought people interessted in a Trusted Boot with OpenBSD? I'm interested
Re: Full disk encryption including /boot, excluding bootloader?
> I'm not really in a position to reflash my machine but I would still be > curious for details. There is no need to reflash your firmware if the system has a integrated and supported TPM 1.2 chip. The prototype uses a Static Root of Trust for Measurment (SRTM) approach where the Chain of Trust is extended from a small immutable firmware part up to boot(8). Every component in the boot chain is responsible for measuring the components, that it hands control over the system. Measuring just means calculating the hash and sending it to the TPM. The following example is the Chain of Trust from my test system Lenovo Thinkpad X240 with OpenBSD. 1: Core Static Root of Trust for Measurment (C-SRTM) (immutable part of the Firmware) 2: Firmware (including OptionROMS) 3: MBR (mbr(8)) 4: PBR (biosboot(8)) 5: boot(8) (residing in the softraid(4) metadata when FDE is enabled) I changed the mbr(8) and biosboot(8) to support measuring their next component. Because there is very little available space left in the 440 byte of the mbr(8) startprogram, you have to choose between CHS and measurement support at compile time. boot(8) got support via a machine specific command to seal and unseal a secret of your choosing to any drive. Sealing and unsealing means encrypting/decrypting data depending on the state of the Platform Control Registers (PCR). PCRs are in the TPM NVRAM and store the measurements. With the laptop being in a trusted state, you can seal a secret and store it on a usb drive. When you want to verify, that the software components are unchanged, you plug in the usb drive and unseal the secret. If the output shows the correct secret and you were the only person knowing it, than there is a very high chance that the early boot components are unchanged. Some feedback from the OpenBSD community on this would also be appreciated. Are there enought people interessted in a Trusted Boot with OpenBSD? Best Regards Julius
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 11:56:24AM +0100, Paul de Weerd wrote: But you can already do this. If your machine supports booting from USB, you can do a minimal install to a USB stick (using FDE, if you want). Now you have a portable OpenBSD environment you can boot on any system capable of booting from USB (and supporting the same kernel architecture). What you can also do with this USB stick is use its bootloader to boot the OS stored on the disk inside your machine (FDE encrypted or not). I've used this to fix up installs gone sour on my machines in the past. Works a treat. I don't use it to prevent the evil maid case you describe though, but I think it would work just fine. | This way the evil maid would have nothing to tamper with. Note that with this approach, a default OpenBSD install to your machine will still install a bootloader on the physical disk inside your machine. It's then on you to NOT use that. That's a heck of a hack!
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 11:13:27AM +0100, Julius Zint wrote: I recently finished my masterthesis that solves this problem by including the Trusted Platform Module (TPM) in the bootprocess of OpenBSD. It extends the Chain of Trust up to boot(8) and allows you to seal a secret of your choice to the platform state. To check wether the unencrypted bootcomponents got tampered with, you can unseal and verify the secret to ensure that the contents of the MBR, PBR and boot(8) are unchanged. it is not exactly the solution you were looking for but it should solves the problem that you describe. Does this sound like something you were willing to try and does your machine have a TPM 1.2 Chip? That sounds absolutely fascinating. Are you familiar with the Heads firmware? How is your approach different? I'm not really in a position to reflash my machine but I would still be curious for details.
Re: Full disk encryption including /boot, excluding bootloader?
>>> How do you do this on OpenBSD? >>@frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk > > That's telling me how to use a keydisk -- how to put the softraid FDE > encryption key material on a USB disk. > > If an evil made came by and got access to my machine, they would still > be able to tamper with the bootloader code to harvest the FDE password > when I returned. > > I want to put the whole bootloader (including the code used to decrypt > the softraid-FDE-encrypted root-partition-containing media) on a USB > disk. > > This way the evil maid would have nothing to tamper with. They still would have plenty of firmware to target/infect, usually under 3 minutes with a screwdriver and dedicated hardware. If going this path, buy a safe and lock the computer while away from it. -Fabio Martins
Re: Full disk encryption including /boot, excluding bootloader?
On Mon, Feb 17, 2020 at 08:50:14AM +, Frank Beuth wrote: | > > How do you do this on OpenBSD? | > @frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk | | That's telling me how to use a keydisk -- how to put the softraid FDE | encryption key material on a USB disk. | | If an evil made came by and got access to my machine, they would still | be able to tamper with the bootloader code to harvest the FDE password | when I returned. | | I want to put the whole bootloader (including the code used to decrypt | the softraid-FDE-encrypted root-partition-containing media) on a USB | disk. But you can already do this. If your machine supports booting from USB, you can do a minimal install to a USB stick (using FDE, if you want). Now you have a portable OpenBSD environment you can boot on any system capable of booting from USB (and supporting the same kernel architecture). What you can also do with this USB stick is use its bootloader to boot the OS stored on the disk inside your machine (FDE encrypted or not). I've used this to fix up installs gone sour on my machines in the past. Works a treat. I don't use it to prevent the evil maid case you describe though, but I think it would work just fine. | This way the evil maid would have nothing to tamper with. Note that with this approach, a default OpenBSD install to your machine will still install a bootloader on the physical disk inside your machine. It's then on you to NOT use that. Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: Full disk encryption including /boot, excluding bootloader?
> > If an evil made came by and got access to my machine, they would still > be able to tamper with the bootloader code to harvest the FDE password > when I returned. > > I want to put the whole bootloader (including the code used to decrypt > the softraid-FDE-encrypted root-partition-containing media) on a USB > disk. > > This way the evil maid would have nothing to tamper with. I recently finished my masterthesis that solves this problem by including the Trusted Platform Module (TPM) in the bootprocess of OpenBSD. It extends the Chain of Trust up to boot(8) and allows you to seal a secret of your choice to the platform state. To check wether the unencrypted bootcomponents got tampered with, you can unseal and verify the secret to ensure that the contents of the MBR, PBR and boot(8) are unchanged. it is not exactly the solution you were looking for but it should solves the problem that you describe. Does this sound like something you were willing to try and does your machine have a TPM 1.2 Chip? Best regards Julius
Re: Full disk encryption including /boot, excluding bootloader?
On Sat, Feb 15, 2020 at 12:22:02PM +0100, no@s...@mgedv.net wrote: >depends what you want to achieve, but my recommendation is booting from USB >and mount encrypted root from the HDD. >you can safely remove the usb key after root mount and all your configs/etc >files are used from the encrypted storage. >this ensures 2 things: bootloader + kernel on USB boot media cannot be >attacked during system uptime and all bytes on disk are encrypted. >another advantage is, you don't need (to type, write down or remember) any >passphrases but can use strong random data for crypto payload/keys. > How do you do this on OpenBSD? @frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk That's telling me how to use a keydisk -- how to put the softraid FDE encryption key material on a USB disk. If an evil made came by and got access to my machine, they would still be able to tamper with the bootloader code to harvest the FDE password when I returned. I want to put the whole bootloader (including the code used to decrypt the softraid-FDE-encrypted root-partition-containing media) on a USB disk. This way the evil maid would have nothing to tamper with.
Re: Full disk encryption including /boot, excluding bootloader?
> >depends what you want to achieve, but my recommendation is booting from > USB > >and mount encrypted root from the HDD. > >you can safely remove the usb key after root mount and all your configs/etc > >files are used from the encrypted storage. > >this ensures 2 things: bootloader + kernel on USB boot media cannot be > >attacked during system uptime and all bytes on disk are encrypted. > >another advantage is, you don't need (to type, write down or remember) any > >passphrases but can use strong random data for crypto payload/keys. > > > > How do you do this on OpenBSD? @frank: https://www.openbsd.org/faq/faq14.html#softraidFDEkeydisk
Re: Full disk encryption including /boot, excluding bootloader?
On Thu, Feb 13, 2020 at 01:31:43PM +0100, no@s...@mgedv.net wrote: depends what you want to achieve, but my recommendation is booting from USB and mount encrypted root from the HDD. you can safely remove the usb key after root mount and all your configs/etc files are used from the encrypted storage. this ensures 2 things: bootloader + kernel on USB boot media cannot be attacked during system uptime and all bytes on disk are encrypted. another advantage is, you don't need (to type, write down or remember) any passphrases but can use strong random data for crypto payload/keys. How do you do this on OpenBSD?
Re: Full disk encryption including /boot, excluding bootloader?
no@s...@mgedv.net(nos...@mgedv.net) on 2020.02.13 13:31:43 +0100:
> > > On Linux you can do the following:
> > > { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive
> entirely encrypted] }
> ... which i would consider to be as insecure, as unencrypted root at all.
... which totaly depends on what you are trying to protect your laptop/data
from.
The lost/stolen laptop szenario is covered nicely by what OpenBSD offers.
Re: Full disk encryption including /boot, excluding bootloader?
> > On Linux you can do the following:
> > { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive
entirely encrypted] }
... which i would consider to be as insecure, as unencrypted root at all.
maybe check out https://wiki.osdev.org, they have nice articles on this.
IMHO a secure boot chain is only possible using a secured, open source bios,
removing all firmware like IME and such.
in such a BIOS you'd save a checksum of the bootloader to NVRAM and refuse
booting if the checksum is incorrect.
altering fw/kernel/boot loader is a common attack vector and if the hardware
is not in a secured room, it's anyways attackable.
depends what you want to achieve, but my recommendation is booting from USB
and mount encrypted root from the HDD.
you can safely remove the usb key after root mount and all your configs/etc
files are used from the encrypted storage.
this ensures 2 things: bootloader + kernel on USB boot media cannot be
attacked during system uptime and all bytes on disk are encrypted.
another advantage is, you don't need (to type, write down or remember) any
passphrases but can use strong random data for crypto payload/keys.
Re: Full disk encryption including /boot, excluding bootloader?
cipher-hea...@riseup.net writes:
>
> On Linux you can do the following:
>
> Hard drive:
> { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive entirely
> encrypted] }
>
> Then the only parts of the (x64) computer that are unencrypted are the BIOS
> and GRUB.
This is how it already does it with the exception that the unencrypted
data are not in a regular partition. Instead the unencrypted
bootloader exists within the space allocated for the disklabel (and
the MBR on x86) which then locates and decrypts the partition
containing the kernel.
> You can then move the GRUB offline if you wish, execute it externally.
>
>
> Is something like this possible on OpenBSD?
I have briefly looked into locating the unencrypted parts of OpenBSD's
bootloader on a seperate detachable disc, as I had managed to cobble
together previously, but the kernel is told where its root partition
is in quite a different way from Linux and I decided I didn't want
to trawl through x86 real mode assembly any more.
It can be done of course but you may have to hack at the bootloader
to make it work. I only did it with Linux to prove that I could not
because it was useful.
Matthew
Re: Full disk encryption including /boot, excluding bootloader?
On Thu, Feb 13, 2020 at 10:31:30AM +, cipher-hea...@riseup.net wrote:
>
> On Linux you can do the following:
>
> Hard drive:
> { [1MB unencrypted GRUB bootloader partition] [Rest of hard drive entirely
> encrypted] }
>
> Then the only parts of the (x64) computer that are unencrypted are the BIOS
> and GRUB.
>
> You can then move the GRUB offline if you wish, execute it externally.
>
>
> Is something like this possible on OpenBSD?
>
Yes, see FAQ: http://www.openbsd.org/faq/faq14.html#softraidFDE
-Otto
Full disk encryption including /boot, excluding bootloader?
On Linux you can do the following:
Hard drive:
{ [1MB unencrypted GRUB bootloader partition] [Rest of hard drive entirely
encrypted] }
Then the only parts of the (x64) computer that are unencrypted are the BIOS and
GRUB.
You can then move the GRUB offline if you wish, execute it externally.
Is something like this possible on OpenBSD?
Re: Request for recommendation - encryption and signature for file backup
Aham Brahmasmi wrote: >If I am not wrong, the verification should fail. If you have a system that uses private / public signing keys then, yes, you're correct. But: 1) In my opinion it's probably overkill for just doing backups. As I said in my previous email, just using symmetric encryption and encrypting in advance the few files you really care about is probably good enough and simpler. 2) You'll have to remember to encrypt your private signing key (using some symmetric encryption like aes256) before you make a backup of it. >Let us assume I get access to the download server and I replace the >perl based installer with a rust based installer in the bsd.rd. I also >change the SHA256.sig file. I do not think I will fool anybody who uses >signify to verify the all-new-improved-rust-based-installer bsd.rd with >the base.pub. That's right, because the public keys are already in /etc/signify and the signature verification would fail. The use of public / private keys here is necessary because files are distributed to other people and these other people must not have access to the private key. In your case there is no "other people" so using public / private keys is probably more than you need. A simple symmetric encryption with just a password would be good enough in my opinion (but it's only my opinion, it's up to you to decide what's best for you). You have to ask yourself: what are the problems that I am trying to defend against? Then use the simplest solution that solves those problems. Be practical, and don't waste time trying to defend against threats which are only theoretical. >For files like compressed database backups, I am not sure I can >determine whether a file has been correctly decrypted or not by looking >at whether the result looks like random garbage. Well, then, you have a good reason to use signatures. Note that it still does not require a public / private key system. You could just compute a hash of your DB (before encryption) and then store the hash on your backup system (no need to encrypt the hash) together with the encrypted DB (encrypted using symmetric encryption and a password). Then later you would: 1) decrypt the DB 2) compute the hash of the decrypted DB and check that it matches the hash from the backup system. Note that in that case the hash must be created *before* you encrypt the DB, not after, otherwise you will not be able to detect a change done to both the file and the hash on the backup system (as I said in my previous email). Anyway, it's up to you to decide what you want to do and whether you need a hash and / or public / private keys, but my advice is to keep your system as simple as possible. Philippe
Re: Request for recommendation - encryption and signature for file backup
On Sat, 4 Jan 2020, Philippe Meunier wrote: > Roderick wrote: > >I do use openssl for encrypting files in my laptop. > > So do I. I only encrypt the 0.001% of files that are really important and > then those files are encrypted on my computer too, not just on the backup > system [...] I have an encrypted partition, that I mount only when necessary. Perhaps that is also an alternative for Aham: mount, send backup, umount. Rodrigo
Re: Request for recommendation - encryption and signature for file backup
Namaste Philippe, Merci beaucoup for your reply. > Sent: Saturday, January 04, 2020 at 3:54 PM > From: "Philippe Meunier" > To: "Aham Brahmasmi" > Cc: misc@openbsd.org, Roderick > Subject: Re: Request for recommendation - encryption and signature for file > backup > > >Aham Brahmasmi wrote: > >> In my limited understanding, to securely backup and restore a file, the > >> steps are: > >> > >> To backup: > >> Step 1 - encrypt the file using a tool > >> Step 2 - sign the encrypted file using a tool > >> Step 3 - backup the signature and the encrypted file > >> > >> To restore: > >> Step 1 - verify the encrypted backup with its signature > >> If Step 1 exits with success, > >> Step 2 - decrypt backup to file > >> If Step 2 exits with success, > >> Step 3 - use file to restore > > The signature verification step is useless: if someone can change an > encrypted file on your backup system then they can change the corresponding > signature file on the same backup system too. I am not a cryptographer, and neither am I a math expert. Let us assume that someone has access to the backup - both the encrypted file and its signature. This person does not have access to the encryption key and the private signing key - else this discussion is moot. This person changes the encrypted file and the corresponding signature file as well. Now, when this modified file is verified against the modified signature using the public signing key, would the verification fail or succeed? If I am not wrong, the verification should fail. In short, this is by definition of signature itself. For a longer explanation, to generate a valid signature, this person will need to have access to the private signing key. Since this person does not have access to the private signing key, the person can modify the encrypted file, but not generate a valid signature of the modified encrypted file. And modifying the original signature does not mean much - the verification with the public signing key will fail. For example, consider the OpenBSD release signing system. (I think) Theo signs the releases using a private signing key. If I am not wrong, only Theo has access to the private signing key, but we all have access to the public signing key. The bsd.rd is released along with its signature in the SHA256.sig file. We run signify(1) to verify the bsd.rd with its signature in the SHA256.sig file and the base.pub public signing key. Let us assume I get access to the download server and I replace the perl based installer with a rust based installer in the bsd.rd. I also change the SHA256.sig file. I do not think I will fool anybody who uses signify to verify the all-new-improved-rust-based-installer bsd.rd with the base.pub. And if you think I came up with this, no. I have only rehashed tedu@'s paper on signify - https://www.openbsd.org/papers/bsdcan-signify.html > If you use (symmetric) encryption then there is probably no need for a > signature in your simple use case anyway: if the encrypted file correctly > decrypts (which is usually easy to tell for data files like text or images) > with the password that only you know then you can assume that nobody > changed the content of the encrypted file on your backup system. If > someone changed the content of the encrypted file on your backup system > then, when you try to decrypt it, either the decrypt will fail or the > result will look like random garbage (hence the "usually easy" above). For files like compressed database backups, I am not sure I can determine whether a file has been correctly decrypted or not by looking at whether the result looks like random garbage. > If your goal is just to prevent people from looking at the content of your > file if they somehow access your backup system then encryption is really > all you need. If you're worried that people might actively try to attack > you through your backup system then you have bigger problems which are > probably beyond what random people on a mailing list can help you with... In the case of compressed database backups, it may also be possible that the backup may have changed due to bit-rot. So decrypting the backup and restoring it assuming no bit-rot may not be exactly preferable. > Roderick wrote: > >I do use openssl for encrypting files in my laptop. > > So do I. I only encrypt the 0.001% of files that are really important and > then those files are encrypted on my computer too, not just on the backup > system (because if a file is important enough to be encrypted on your > backup system then it's probably important enough to be encrypted on your > computer too). Something like: > > openssl enc -aes256 -e < foo > foo.aes256 > > t
Re: Request for recommendation - encryption and signature for file backup
>Aham Brahmasmi wrote: >> In my limited understanding, to securely backup and restore a file, the >> steps are: >> >> To backup: >> Step 1 - encrypt the file using a tool >> Step 2 - sign the encrypted file using a tool >> Step 3 - backup the signature and the encrypted file >> >> To restore: >> Step 1 - verify the encrypted backup with its signature >> If Step 1 exits with success, >> Step 2 - decrypt backup to file >> If Step 2 exits with success, >> Step 3 - use file to restore The signature verification step is useless: if someone can change an encrypted file on your backup system then they can change the corresponding signature file on the same backup system too. If you use (symmetric) encryption then there is probably no need for a signature in your simple use case anyway: if the encrypted file correctly decrypts (which is usually easy to tell for data files like text or images) with the password that only you know then you can assume that nobody changed the content of the encrypted file on your backup system. If someone changed the content of the encrypted file on your backup system then, when you try to decrypt it, either the decrypt will fail or the result will look like random garbage (hence the "usually easy" above). If your goal is just to prevent people from looking at the content of your file if they somehow access your backup system then encryption is really all you need. If you're worried that people might actively try to attack you through your backup system then you have bigger problems which are probably beyond what random people on a mailing list can help you with... Roderick wrote: >I do use openssl for encrypting files in my laptop. So do I. I only encrypt the 0.001% of files that are really important and then those files are encrypted on my computer too, not just on the backup system (because if a file is important enough to be encrypted on your backup system then it's probably important enough to be encrypted on your computer too). Something like: openssl enc -aes256 -e < foo > foo.aes256 then I delete foo. (To decrypt use the -d option instead of -e; and read carefully the openssl(1) man page before you type the command above because you have no reason to trust me, right?) Then I do backups without worrying about whether a file is encrypted or not. YMMV. Philippe
Re: Request for recommendation - encryption and signature for file backup
Namaste Rodrigo, Thank you for your reply. > Sent: Friday, January 03, 2020 at 5:43 PM > From: "Roderick" > To: "Aham Brahmasmi" > Cc: misc@openbsd.org > Subject: Re: Request for recommendation - encryption and signature for file > backup > > > I would perhaps write a script that calls openssl for encripting and > signing, rsync to send new files, something simple. > > I do use openssl for encrypting files in my laptop. > > Rodrigo If I am not wrong, some time ago, solene@ wrote a blog post about using openssl for encrypting files. She later modified it to recommend existing backup tools. I think there was some feedback with respect to her usage of openssl and cryptography, but I do not exactly remember what it was. I cannot find the original blog post, but the modified one is available at https://dataswamp.org/~solene/2018-06-26-openbsd-easy-backup.html Perhaps, may be solene@ would be able to throw more light on the openssl feedback. > > On Thu, 2 Jan 2020, Aham Brahmasmi wrote: > > > Namaste misc, > > > > What tool(s) would you recommend to encrypt and sign a file - correctly > > - for backup? > > > > I possess a limited ability to read code, and I am certainly not a > > cryptographer. > > > > In my limited understanding, to securely backup and restore a file, the > > steps are: > > > > To backup: > > Step 1 - encrypt the file using a tool > > Step 2 - sign the encrypted file using a tool > > Step 3 - backup the signature and the encrypted file > > > > To restore: > > Step 1 - verify the encrypted backup with its signature > > If Step 1 exits with success, > > Step 2 - decrypt backup to file > > If Step 2 exits with success, > > Step 3 - use file to restore > > > > For the tools to encrypt and sign, I think I may use the following: > > > > For encryption: encpipe > > encpipe (https://github.com/jedisct1/encpipe) is ISC licenced, written > > in C by Monsieur Denis and seems simple. If there is one thing that I > > know - and I admit I don't know much - all things being equal, simple > > beats complex. > > > > However, I do not understand the math underlying the tool or whether all > > things are indeed equal - possible attack vectors, mitigations et al. > > And hence, my request. > > > > For signature: signify > > I think signify may suffice for signature. For other platforms, minisign > > (https://github.com/jedisct1/minisign) is compatible with signify. > > > > Dhanyavaad, > > ab > > -|-|-|-|-|-|-|-- Dhanyavaad, ab -|-|-|-|-|-|-|--
Re: Request for recommendation - encryption and signature for file backup
I would perhaps write a script that calls openssl for encripting and signing, rsync to send new files, something simple. I do use openssl for encrypting files in my laptop. Rodrigo On Thu, 2 Jan 2020, Aham Brahmasmi wrote: > Namaste misc, > > What tool(s) would you recommend to encrypt and sign a file - correctly > - for backup? > > I possess a limited ability to read code, and I am certainly not a > cryptographer. > > In my limited understanding, to securely backup and restore a file, the > steps are: > > To backup: > Step 1 - encrypt the file using a tool > Step 2 - sign the encrypted file using a tool > Step 3 - backup the signature and the encrypted file > > To restore: > Step 1 - verify the encrypted backup with its signature > If Step 1 exits with success, > Step 2 - decrypt backup to file > If Step 2 exits with success, > Step 3 - use file to restore > > For the tools to encrypt and sign, I think I may use the following: > > For encryption: encpipe > encpipe (https://github.com/jedisct1/encpipe) is ISC licenced, written > in C by Monsieur Denis and seems simple. If there is one thing that I > know - and I admit I don't know much - all things being equal, simple > beats complex. > > However, I do not understand the math underlying the tool or whether all > things are indeed equal - possible attack vectors, mitigations et al. > And hence, my request. > > For signature: signify > I think signify may suffice for signature. For other platforms, minisign > (https://github.com/jedisct1/minisign) is compatible with signify. > > Dhanyavaad, > ab > -|-|-|-|-|-|-|-- > >
Re: Request for recommendation - encryption and signature for file backup
Hallo Claus, Danke for your reply. > Sent: Thursday, January 02, 2020 at 6:38 PM > From: "Claus Assmann" > To: misc@openbsd.org > Subject: Re: Request for recommendation - encryption and signature for file > backup > > Maybe duplicity? It's available as package (not sure > whether it does signing). I apologize for not completely explaining my original query. I am aware of backup tools that can encrypt and/or sign and/or deduplicate. Duplicity, restic, borg et al. I am trying to ascertain what tool would misc@ recommend to encrypt and then sign the file. This encrypted file and its signature would then be handed over to a backup tool - duplicity/restic/borg or even a custom script. In other words, it would be preferable for the backup tool to not do cryptography, but pick up the file after it has been encrypted and signed. And hence, my request. I now understand that my original mail was not at all clear on this. My mistake. With respect to duplicity [1], if I am not wrong, it uses GnuPG for the cryptography part. I think the following blog post is quite informative about PGP, GnuPG et al: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html That blog post itself links to the following paper by tedu@: https://www.openbsd.org/papers/bsdcan-signify.html I did not understand the cryptographic aspects of the latacora post, but I understood that a dedicated file encryption tool was desirable. Also, signify(1)/minisign would be a good fit for the signature part. I understand that "age" as suggested in that blog post was recently added to ports - Thanks abieber@ for that. However, if I am not wrong, it is still in beta. Dhanyavaad, ab [1] - http://duplicity.nongnu.org/ -|-|-|-|-|-|-|--
Re: Request for recommendation - encryption and signature for file backup
Maybe duplicity? It's available as package (not sure whether it does signing). -- Address is valid for this mailing list only.
Request for recommendation - encryption and signature for file backup
Namaste misc, What tool(s) would you recommend to encrypt and sign a file - correctly - for backup? I possess a limited ability to read code, and I am certainly not a cryptographer. In my limited understanding, to securely backup and restore a file, the steps are: To backup: Step 1 - encrypt the file using a tool Step 2 - sign the encrypted file using a tool Step 3 - backup the signature and the encrypted file To restore: Step 1 - verify the encrypted backup with its signature If Step 1 exits with success, Step 2 - decrypt backup to file If Step 2 exits with success, Step 3 - use file to restore For the tools to encrypt and sign, I think I may use the following: For encryption: encpipe encpipe (https://github.com/jedisct1/encpipe) is ISC licenced, written in C by Monsieur Denis and seems simple. If there is one thing that I know - and I admit I don't know much - all things being equal, simple beats complex. However, I do not understand the math underlying the tool or whether all things are indeed equal - possible attack vectors, mitigations et al. And hence, my request. For signature: signify I think signify may suffice for signature. For other platforms, minisign (https://github.com/jedisct1/minisign) is compatible with signify. Dhanyavaad, ab -|-|-|-|-|-|-|--
Re: Full Disk Encryption and (U)pgrade via snapshot installer?
Thank you for the tip there Maksym! I'll be sure to remember it. On Thu, Jul 04, 2019 at 12:59:37PM +0300, Maksym Sheremet wrote: > In -current you should create sd0 manually. > > # cd /dev && sh MAKEDEV sd0 > > And then use bioctl as usual. > > On Thu, Jul 04, 2019 at 02:02:39AM +, Chris Humphries wrote: > > Hello, > > > > I have full disk encryption active on my machine. I would like to > > follow -current, and the FAQ[1] said to grab an install image for a > > snapshot and (U)pgrade. > > > > The problem is, I'm not sure how to manually get my FDE disk live via > > shell from the installer. > > > > I tried doing disklabel on likely candidates, but disklabel claims wd0 > > device not configured and sd0 doesn't exist. I didn't see anything > > obvious on the -current FAQ. > > > > Is it possible to do an upgrade from the installer for a FDE disk? > > > > Thank you! > > > > 1: https://www.openbsd.org/faq/current.html > > > > > > -- > > Chris Humphries > > 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29 > > > > -- > MS
Re: Full Disk Encryption and (U)pgrade via snapshot installer?
In -current you should create sd0 manually. # cd /dev && sh MAKEDEV sd0 And then use bioctl as usual. On Thu, Jul 04, 2019 at 02:02:39AM +, Chris Humphries wrote: > Hello, > > I have full disk encryption active on my machine. I would like to > follow -current, and the FAQ[1] said to grab an install image for a > snapshot and (U)pgrade. > > The problem is, I'm not sure how to manually get my FDE disk live via > shell from the installer. > > I tried doing disklabel on likely candidates, but disklabel claims wd0 > device not configured and sd0 doesn't exist. I didn't see anything > obvious on the -current FAQ. > > Is it possible to do an upgrade from the installer for a FDE disk? > > Thank you! > > 1: https://www.openbsd.org/faq/current.html > > > -- > Chris Humphries > 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29 > -- MS
Re: Full Disk Encryption and (U)pgrade via snapshot installer?
Hey Chris, Running the bioctl command at the bottom will also decrypt the partition. It’s not obvious in the FAQ. It’s at the very bottom. With my setup, I was afraid of overwriting it, but that’s how to open it. The method you used also works! Cheers, Zack Lofgren > On Jul 3, 2019, at 20:21, Chris Humphries wrote: > > PEBKAC error. I misread the instructions. > > Incorrect: creating a snapshot installer usb key and booting off it. > > Correct: copying bsd.rd from snapshots to my filesystem, booting off of it, > and then (U)pgrade. > > :| > > >> On Thu, Jul 04, 2019 at 02:02:39AM +, Chris Humphries wrote: >> Hello, >> >> I have full disk encryption active on my machine. I would like to >> follow -current, and the FAQ[1] said to grab an install image for a >> snapshot and (U)pgrade. >> >> The problem is, I'm not sure how to manually get my FDE disk live via >> shell from the installer. >> >> I tried doing disklabel on likely candidates, but disklabel claims wd0 >> device not configured and sd0 doesn't exist. I didn't see anything >> obvious on the -current FAQ. >> >> Is it possible to do an upgrade from the installer for a FDE disk? >> >> Thank you! >> >> 1: https://www.openbsd.org/faq/current.html >> >> > > -- > Chris Humphries > 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29 >
Re: Full Disk Encryption and (U)pgrade via snapshot installer?
PEBKAC error. I misread the instructions. Incorrect: creating a snapshot installer usb key and booting off it. Correct: copying bsd.rd from snapshots to my filesystem, booting off of it, and then (U)pgrade. :| On Thu, Jul 04, 2019 at 02:02:39AM +, Chris Humphries wrote: > Hello, > > I have full disk encryption active on my machine. I would like to > follow -current, and the FAQ[1] said to grab an install image for a > snapshot and (U)pgrade. > > The problem is, I'm not sure how to manually get my FDE disk live via > shell from the installer. > > I tried doing disklabel on likely candidates, but disklabel claims wd0 > device not configured and sd0 doesn't exist. I didn't see anything > obvious on the -current FAQ. > > Is it possible to do an upgrade from the installer for a FDE disk? > > Thank you! > > 1: https://www.openbsd.org/faq/current.html > > -- Chris Humphries 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29
Full Disk Encryption and (U)pgrade via snapshot installer?
Hello, I have full disk encryption active on my machine. I would like to follow -current, and the FAQ[1] said to grab an install image for a snapshot and (U)pgrade. The problem is, I'm not sure how to manually get my FDE disk live via shell from the installer. I tried doing disklabel on likely candidates, but disklabel claims wd0 device not configured and sd0 doesn't exist. I didn't see anything obvious on the -current FAQ. Is it possible to do an upgrade from the installer for a FDE disk? Thank you! 1: https://www.openbsd.org/faq/current.html -- Chris Humphries 5223 9548 E1DE DE87 F509 1888 8141 8451 6338 DD29
Re: OT: Firmware encryption hacked?
Many thanks to all for your explanations, as always. Regards, C. L. Martinez From: owner-m...@openbsd.org on behalf of Kevin Chadwick Sent: 13 September 2018 17:39 To: misc@openbsd.org Subject: Re: OT: Firmware encryption hacked? On Thu, 13 Sep 2018 10:23:11 -0400 > > Uhmm … Reality? > > https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1 > > Somewhat better writup from the source: > > https://blog.f-secure.com/cold-boot-attacks/ > > The vulnerability seems to be when a computer is running or "sleeping" > not actually off or hibernating. There are then ways that an attacker > with physical access might recover encryption keys or other data from > RAM. Old news. Also, cold boot attacks go atleast several years before 2008. In fact, expensive cold boot resistant hdd were around in 2005.
Re: OT: Firmware encryption hacked?
On Thu, 13 Sep 2018 10:23:11 -0400 > > Uhmm … Reality? > > https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1 > > > > Somewhat better writup from the source: > > https://blog.f-secure.com/cold-boot-attacks/ > > The vulnerability seems to be when a computer is running or "sleeping" > not actually off or hibernating. There are then ways that an attacker > with physical access might recover encryption keys or other data from > RAM. Old news. Also, cold boot attacks go atleast several years before 2008. In fact, expensive cold boot resistant hdd were around in 2005.
Re: OT: Firmware encryption hacked?
Carlos Lopez writes: > Uhmm … Reality? > https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1 Somewhat better writup from the source: https://blog.f-secure.com/cold-boot-attacks/ The vulnerability seems to be when a computer is running or "sleeping" not actually off or hibernating. There are then ways that an attacker with physical access might recover encryption keys or other data from RAM.
OT: Firmware encryption hacked?
Uhmm … Reality? https://techcrunch.com/2018/09/12/security-flaw-in-nearly-all-modern-pcs-and-macs-leaks-encrypted-data/?guccounter=1 Can we consider a risk to encrypt at OS level also?
Re: NSA encryption algorithms in Linux kernel, OpenBSD too?
> On Aug 7, 2018, at 7:15 AM, Kevin Chadwick wrote: > > On Mon, 6 Aug 2018 15:52:11 -0500 > It may be more likely that some zealous chrome devs > decided https everywhere was utterly important and so misleading > messages were the order of the day. For some reason I thought https everywhere was a government initiative. Or perhaps they just followed the trend. Bryan
Re: NSA encryption algorithms in Linux kernel, OpenBSD too?
On Mon, 6 Aug 2018 15:52:11 -0500 > I imagine the answer is this is not implemented or going to be but > saw this article and figured I would ask. > > Seems suspect to not release all details, and have it rejected by ISO > but yet still being put in both the kernel and Android OS. > > https://itsfoss.com/nsas-encryption-algorithm-in-linux-kernel-is-creating-unease-in-the-community/ I wouldn't be too concerned in any case. It is not like OpenBSD devs are likely to switch out AES-NI support from the filesystem encryption. Rarely is well implemented encryption the weak spot. Considering the Nistp allegations have been largely discredited and AES and SHA256 hw even is abound on modern hardware, I doubt they focus on encryption itself! If you want to talk conspiracies then Google Chromes blunder of calling sites SECURE becoming a repeated blunder of NOT SECURE, when they already had a better implementation of flashing the bar red during data entry? https sites that provide http unsigned downloads are quite frequent too! It is interesting that Google apparently say AES is expensive here yet where an attacker may saturate your website, https is apparently faster than http. (RTT potential, ignoring the negative sides in literature and youtube completely). I guess it is possible that https deployment may mean Google cloud makes money in CPU cycles from CHACHA or competitors energy costs go up (older non AES-NI). Or VPN usage declines, so Google can target ads to IP location. It may be more likely that some zealous chrome devs decided https everywhere was utterly important and so misleading messages were the order of the day.
NSA encryption algorithms in Linux kernel, OpenBSD too?
I imagine the answer is this is not implemented or going to be but saw this article and figured I would ask. Seems suspect to not release all details, and have it rejected by ISO but yet still being put in both the kernel and Android OS. https://itsfoss.com/nsas-encryption-algorithm-in-linux-kernel-is-creating-unease-in-the-community/ Thank you, -- Edward Lopez-Acosta
Encryption of two disks on the same host
I want to use full disk encryption on all of the disks of a host (two hosts). They can have the same password. How should I do this? 1. A method that I know will work is to make separate CRYPTO discipline softraid devices for each disk, install on one of them; and configure and mount the other disk encryption by calling bioctl rc.local. I would either type the password twice or use a keydisk stored on the first softraid device. 2. I could make a RAID 0 or CONCAT discipline device to combine the two devices and then make a CRYPTO discipline device on top of that, but my reading of the manual pages suggests that I can't install boot(8) on this. 3. Perhaps I could do the option 2 and add a new disk (SD card) that I use just for installing boot(8). (If I'm doing that, I might use the same SD card for both boot and keydisk.) Are there other approaches I should consider? And, if I want to put boot on a separate disk, which question in the installer do I specify that in?
