I was researching options for zfs encryption since I was buying a bunch of used hdd to expand storage and since some going to be DOA I wanted to encrypt data for returns. And then I saw a post somewhere how flawed design decisions for using disk transparent encryption with using zfs on top of it.
Well, I've tested it myself, unfortunately :(
The maintainers went the extra mile to warn about looking passphrase and restore key. And then casually mention about disk specific master keys - don't worry about those because looking that key is equivalent of losing a disk and zfs would tolerate with redundant arrays.
What they didn't mention that the master key is unique for each disk AND it's stored in the last sector of the disk. Now, the original software that handles all this encryption has sane default settings: it _backups up_ the master key when the disk encryption is initialized. Because this key is part of the disk itself and accessible there. So why not store it as duplicated just in case, right?!
And developers of geli software had good reasons to provide master keys backups by default. Why? Because they made their own strange design choices - the key is stored in the last sector of "provider". And that last sector is quite popular among other utilities that like to mess with the disk partition table, raid configs etc. I found somebody complained about gpart on FreeBSD mailing list, that gpart label would overwrite it.
There is also a piece of crap called MegaCli that bit me: its PDMakeJBOD command overwrites the last sector with zeroes.
But what I don't get, why developers disabled backup of keys?! ('-B None' option) https://github.com/freenas/freenas/...wared/plugins/disk_/encryption_freebsd.py#L62
Well, I've tested it myself, unfortunately :(
The maintainers went the extra mile to warn about looking passphrase and restore key. And then casually mention about disk specific master keys - don't worry about those because looking that key is equivalent of losing a disk and zfs would tolerate with redundant arrays.
What they didn't mention that the master key is unique for each disk AND it's stored in the last sector of the disk. Now, the original software that handles all this encryption has sane default settings: it _backups up_ the master key when the disk encryption is initialized. Because this key is part of the disk itself and accessible there. So why not store it as duplicated just in case, right?!
And developers of geli software had good reasons to provide master keys backups by default. Why? Because they made their own strange design choices - the key is stored in the last sector of "provider". And that last sector is quite popular among other utilities that like to mess with the disk partition table, raid configs etc. I found somebody complained about gpart on FreeBSD mailing list, that gpart label would overwrite it.
There is also a piece of crap called MegaCli that bit me: its PDMakeJBOD command overwrites the last sector with zeroes.
But what I don't get, why developers disabled backup of keys?! ('-B None' option) https://github.com/freenas/freenas/...wared/plugins/disk_/encryption_freebsd.py#L62
