O. Hartmann wrote this message on Mon, Oct 19, 2015 at 06:19 +0200: > For me, I'd like to know what is the benefit/performance of each technique and > a clear preparation of each ones advantages over the other. That would make the > decission process much easier and hopefully would not scare people away and > announce "FreeBSD does not have a, b, c, ..." ... So, one thing that the docs talk about is that geli uses the crypto(9) framework. This doesn't mean much on it's own, but if you have a machine with AES-NI instructions or an accelerator card that supports the cipher mode used, then you can get faster performance of hardware off load, while gbde uses the software only routines which are slow.. I have put work into making AES-XTS very fast on AES-NI capable machines... On my test machine, I get about 1GB/sec on gzero... This is close to real world (assuming infitely fast disc) vs. just running the algorithm and posting those results (which result in 2GB/sec+ on the same machine)... You will not be able to achive that level of performance w/ gbde. Also, gbde uses CBC, while having some better crypto properties than XTS, would require significant rewrite of gbde to make it perform... I just noticed that the handbook also fails to mention that geli has a mode that will verify the integrity of data which gbde does not have.. As we have discovered, if you can't authenticate your data, you really can't trust it... I personally have decided that I will use ZFS's sha256 checksums of the data as my integrity protection mechanism.. It is highly unlikely that an attacker would be able to corrupt two AES-XTS blocks to cause the sha256 checksum to match what they corrupted other blocks to become... So, in this reguard, if you run gbde w/ ZFS w/ sha256 checksums, then are equivalent (besides the performance difference)... I personally run geli encryption on my 8 drive ZFS array at home. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."Received on Mon Oct 19 2015 - 18:50:17 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:00 UTC