Introdution

Basically the goal will be to define an encrypted filesystem for all files requiring such feature.

All the rest of OpenBSD remains standard, thus unencrypted.

Create a RAID filesystem during installation process

During the installation process, define an extra filesystem.
For that you have to enter in the DISKLABEL process and put RAID as filesystem type for one filesystem.
In the following example, I've added a filesystem "j". It will most probably be another letter in your case.

sd0> a j
offset: [213969647]
size: 20G
FS type: [4.2BSD] RAID

Once the DISKLABEL finalized, you can continue by typing

sd0> w
sd0> q

You have to define your own filesystems and their respective sizes.
You can be inspired by what the installation process proposes for your specific situation. You note those different values on a paper, then interrupt the process (ctrl-c) and restart it by typing "install". Once you arrive to the disk layout, enter into the manual process of DISKLABEL

For the rest, just follow the installation processes.

Create an encrypted filesystem

After having rebooted on your brand new OpenBSD system, you can encrypt your filesystem

Please adapt the disk in the following command to your own case !!!

# bioctl -c C -l sd0j softraid0
New passphrase:
Re-type passphrase:
sd1 at scsibus2 targ 1 lun 0: <OPENBSD, SR CRYPTO, 005> SCSI2 0/direct fixed
sd1: 19445MB, 512 bytes/sector, 39824607 sectors
softraid0: CRYPTO volume attached as sd1

Type a strong but well defined password. There is no way to recover it in case you forget it !!!!
So be very smart with this password.

As you can see, a pseudo disk sd1 has been created. Once again, depending on your specific case, this could be sd2 or sd3, ... Does not matter, but adapt this value in further commands

Then we will create a filesystem on this encrypted pseudo disk.

# dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
# fdisk -iy sd1
# newfs sd1c

Here I'm creating the filesystem on the whole sd1 pseudo disk as mapped to letter "c".

At this stage, you can mount or umount it as a usual filesystem by refering to /dev/sd1c.

In case you have umounted it, you must also remove his pseudo disk by doing:

bioctl -d sd1

Mounting and umounting this new encrypted filesystem

mounting

To mount it, you have to do it in 2 steps:

# bioctl -c C -l sd0j softraid0
password: 
softraid0: CRYPTO volume attached as sd1

There you must insert the password as defined during the setup process. And bioctl will reply to you which pseudo disk was created. In this case sd1

Then you can mount it:

# mount /dev/sd1c /enc

Your files will be present in /enc like any other filesystem.

To avoid troubles and to facilitate the scripting of such mount process, you can use the DUID of your disk.
this value can be retrieved via the command disklabel:

# disklabel sd0 | grep duid
duid: 0a7595940be2dcc9

In such case, you can perform:

/sbin/bioctl -c C -l 0a7595940be2dcc9.j softraid0

If you want to script this whole process, you could have something like this:

#!/bin.sh

# enc_mount.sh
doas /sbin/bioctl -c C -l 0a7595940be2dcc9.j softraid0 > /tmp/softraid_tmp
device=$(grep "attached" /tmp/softraid_tmp | cut -d' ' -f6)
if [ "$device" = "" ]; then
    cat /tmp/softraid_tmp
else
    mv /tmp/softraid_tmp /tmp/softraid
    device=$(grep "attached" /tmp/softraid | cut -d' ' -f6)
    echo "device:$device"
    doas /sbin/mount /dev/${device}c /enc
fi

Please note that I will use this script with my standard user. This explain the usage of doas

%obsd:~/.local/bin $ enc_mount.sh
Passphrase:
device:sd1
%obsd:~/.local/bin $

unmounting

To unmount, you have to unmount the filsystem and release the pseudo disk created:

# umount /enc
# bioctl -d sd1

Similarly, we could have such script to umount and remove the pseudo disk:

#!/bin/sh

# enc_umount.sh
set -e
doas /sbin/umount /enc
device=$(grep "attached" /tmp/softraid | cut -d' ' -f6)
doas /sbin/bioctl -d $device

Please note that I'm using the file created during the pseudo disk creation in order to know which is this pseudo disk reference.

How much impact has an encrypted filesystem on your machine ?

This is a tricky question on which different responses can be provided.
On my side, I'm interested to save my CPU and thus my battery by avoiding decryption/encryption on none critical files.

Imagine you manage audio file or video files, let's see how this impact your CPU.
Since I'm on a laptop, I make sure the CPU is at the "low consumption" mode before each execution.

In this case I'm building a file of 1.500MB.

%obsd:~ $ apm
Battery state: low, 36% remaining, 64 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: auto (400 MHz)

%obsd:~ $ time dd if=/dev/random of=bigfile bs=1M count=1500
1500+0 records in
1500+0 records out
1572864000 bytes transferred in 11.851 secs (132711408 bytes/sec)
    0m12.03s real     0m00.00s user     0m11.62s system
%obsd:~ $
%obsd:~ $ apm
Battery state: low, 36% remaining, 46 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: auto (2701 MHz)
%obsd:~ $ apm
Battery state: low, 36% remaining, 64 minutes life estimate
AC adapter state: not connected
Performance adjustment mode: auto (400 MHz)

%obsd:~ $ cd /enc
%obsd:/enc $ time dd if=/dev/random of=bigfile bs=1M count=1500
1500+0 records in
1500+0 records out
1572864000 bytes transferred in 15.107 secs (104114858 bytes/sec)
    0m15.28s real     0m00.00s user     0m14.14s system

My encrypted filesystem is mounted on /enc.
I've not print out the apm command between each trials, but I did to make sure that the CPU was always at his "low mode" before the run.

| file size (MB) |standard |encrypted |delta  |
|----------------|---------|----------|-------|
|     1500       |  11,851 |   15,107 |27,47 %|
|      500       |   4     |    5,237 |30,93 %|
|      200       |   1,528 |    2,049 |34,10 %|
|      100       |   0,777 |    0,953 |22,65 %|
|       50       |   0,379 |    0,587 |54,88 %|

This is not a real scientific case, but we can see that the delta is approximately 25%. I do not take into account the measure for the file of 50MB which is too small and measure can be altered via many other events occurring on the machine.

So I conclude, this is not scientific, that the encryption a full disk could eat 25% of my CPU and thus probably same ratio for on my battery.

This is probably not fully exact, but via this measure we see that the extra charge caused by the encryption is not negligible (few percent).

As suggested by Solene in Mastodon, I share with you the results based on Wh consumption.

So, what I do is getting the "Watt hour" remaining before and after the file's creation
to avoid side's effect, I did the following script which will launch each commands as soon as possible.

sysctl hw | grep "remaining capacity" ; time dd if=/dev/random of=bigfile bs=1M count=1500 ; sysctl hw | grep "remaining capacity"

This generate such output:

hw.sensors.acpibat0.watthour3=17.09 Wh (remaining capacity), OK
hw.sensors.acpibat1.watthour3=9.87 Wh (remaining capacity), OK
1500+0 records in
1500+0 records out
1572864000 bytes transferred in 12.156 secs (129385069 bytes/sec)
0m12.39s real     0m00.00s user     0m11.56s system
hw.sensors.acpibat0.watthour3=17.09 Wh (remaining capacity), OK
hw.sensors.acpibat1.watthour3=9.77 Wh (remaining capacity), OK

As you can see, my T460 has 2 batteries, so I add both deltas. In this case the test took 0.10Wh.

| file size (MB) |standard Wh |encrypted Wh | delta |
|----------------|------------|-------------|-------|
|     5500       |   0.25     |    0.34     |  36 % |
|     3500       |   0.11     |    0.23     | 109 % |
|     1500       |   0.05     |    0.11     | 120 % |

Bellow 1500MB measures where too close to 0 and not significant.

My machine has AES enabled:

cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN

Now let's see the impact on a "read".

sysctl hw | grep "remaining capacity" ; time dd if=bigfile  of=/dev/null bs=1M  ; sysctl hw | grep "remaining capacity"

Measures are:

| file size (MB) |standard Wh |encrypted Wh | delta |
|----------------|------------|-------------|-------|
|     5500       |   0.08     |    0.15     |  87 % |
|     3500       |   0.00     |    0.00     |   0 % |

Read a file of 3.5GB is not measurable. Without encryption is take less than 1 seconds and with encryption is take a bit more than 1 second.
With 3 trials to read a file of 5.5GB, we can see that there is a delta of +-80% of Wh usage.

Add files of /etc in my encrypted filesystem.

Thanks to the script enc_mount.sh and enc_umount.sh, we can mount and umount such encrypted filesystem with a normal user.

Most of the files my encrypted filesystem will received are private documents and files.

But we could add files coming from /etc like hostname file for you wifi connection.

Let's see how to manage this for the hostname.iwm0 file containing the wifi passwords.

In this case my enc_mout.sh script becomes:

#!/bin/sh

# enc_mount.sh
doas /sbin/bioctl -c C -l 0a7595940be2dcc9.j softraid0 > /tmp/softraid_tmp
device=$(grep "attached" /tmp/softraid_tmp | cut -d' ' -f6)
if [ "$device" = "" ]; then
    cat /tmp/softraid_tmp
else
    set -e
    mv /tmp/softraid_tmp /tmp/softraid
    device=$(grep "attached" /tmp/softraid | cut -d' ' -f6)
    echo "device:$device"
    doas /sbin/mount /dev/${device}c /enc
    echo "adapt /etc/hostname.iwm0"
    doas ~/.local/bin/enc_switch_file.sh /etc/hostname.iwm0
    echo "netstart iwm0"
    doas ifconfig iwm0 -joinlist
    doas sh /etc/netstart iwm0
fi

You can see the last part of the script adding execution of enc_switch_file.sh and restart of my iwm0 interface.

This enc_switch_file.sh could be like this:

#!/bin/sh

# enc_switch_file.sh
if [ -f "/enc$1" ]; then
    if [ -f "$1" ]; then
        cp -a "$1" "$1_bkp"
        rm "$1"
    fi
    ln -s "/enc$1" "$1"
else
    echo "/enc$1 does not exists. Abandonned"
    exit 1
fi

So, it take a backup of your /etc file and create a link to your file located in /enc.

I prefer to use symbolink links so, visually, I see immediately the situation.

And the enc_umount.sh script becomes like this:

#!/bin/sh

# enc_umount.sh
set -e

doas /sbin/umount /enc
device=$(grep "attached" /tmp/softraid | cut -d' ' -f6)
doas /sbin/bioctl -d $device

echo "adapt /etc/hostname.iwm0"
doas ~/.local/bin/enc_uswitch_file.sh /etc/hostname.iwm0
echo "netstart iwm0"
doas ifconfig iwm0 -joinlist
doas sh /etc/netstart iwm0

Compared to previous enc_umount.sh script, I've added enc_uswitch_file.shs and restart of my wifi connections

In this case, enc_uswitch_file.sh is like this:

#!/bin/sh

#enc_uswitch_file.sh
if [ -h "$1" ]; then
    if [ -f "$1_bkp" ]; then
        rm "$1"
        cp -a "$1_bkp" "$1"
    else
        echo "No backup file available. Link removed"
        rm "$1"
    fi
else
    echo "$1 does not exists. Abandonned"
    exit 1
fi

In short, this script remove the link to /enc and restore the _bkp file via a "cp -a".

Conclusions

We saw that it's not that complex to build an encrypted filesystem if it's planned since the installation process.

We can see that full disk encryption has an effect on hardware resources of our laptop. So the life of the battery.

Thanks to doas, it's possible to keep the usage of such encrypted filesystem to the end user.

We saw that such encrypted filesystem can contain some specific files located in /etc.

Once again, I'm amazed to see how simple, yet flexible, OpenBSD is.