GELI, change default integrity algorithm at installation time

[Xou]

Intro:
Hi, I'm about to switch to FreeBSD for main dailly desktop usage, and I'm concerned about my data and slightly about performance.

Context:
My machine is 64bit and i know (based on what I've read online) that, SHA-512 is faster than SHA-256 on a 64bit system.

Goal:
So, i was wondering if anyone could assist\help me on, how to change the default integrity algorithm at installation time to SHA-512, because I wasn't able to figure it out by myself so far.

PS. Any extra, even non related to the question, recomendation about packages, config files and etc. will be appreciated too.
Thanks in advance for any help.

 

[W.hâ/t]

There are 2 options that I know of.
One is to do the install manually.
The other is to edit the corresponding script in /usr/libexec/bsdinstall/ . For example zfsboot . At diskpart, chose the manual install. You will need to copy the file in a tmpfs dir and edit it there. Run it, ^D

 

[Xou]

I had a look into the zfsboot file, although I found some potential variables like GELI_PASSWORD_INIT and GELI_PASSWORD_GELIBOOT_INIT where I could possibly add the option -a, I'm not sure if that would be the right thing to do.. Anyways, I think I can live without it.

 

[ralphbsz]

Unless this is your hobby and you enjoy wasting time and creating a more unstable system:

Measure (not guess or read!) whether the performance difference between SHA512 and SHA256 (a) is still real, and (b) makes a significant difference.

To point (a): While it is true that SHA512 performs a smaller count of arithmetic operations (each twice as wide though), is may use more memory bandwidth (more rounds). Depending on the size of your data blocks (which is an implementation detail of geli) and how many concurrent operations are going on, that effect could be superlinear, as caches are evicted. And modern processors are more memory/cache constrained than CPU constrained. A huge question in this performance discussion is how well integrated the hashing is with the encryption; performing them simultaneously, one can save significant memory bandwidth by improving cache locality.

To point (b): Compared to all the other latencies of doing IO, I would expect that the cost of the checksum (hashing, integrity) is small; optimizing that a little bit probably has an insignficantly small effect. If this machine is purely a disk server where the CPU does nothing but process GELI-encrypted data blocks all day long, the saving in CPU cycles might improve overall performance somewhat. If this is an end-user machine where the data is actually consumed by processes that use significant (and variable) CPU power, the effect of SHA512 versus SHA256 is likely tiny.