BUILD Encryption hardware

[cr6zed]

Ok. This is going to be a loaded and long question and may branch off in segways.
First my hardware (can't find a section in profiles for a permanent hardware for me):
gigabyte horus full tower, Gigabyte ga- something... It has a 6000+ with 8gig RAM (and before you server dudes start the RAM bashing, it was to get me started)...I have an Intel 5520 w/ 12gig ECC and a x5570 on the way in the post (I had already purchased 2x 5570 - Don't judge, they were $30 for the pair and 2x 56xx are on my wishlist, but pricey and my bloody brother has a a server with a pair of them (jealous). AES-NI and that.).
2xWD SAS 4TB, a 5TB sata 3, 2....blah blah. Setup in single ZFS each (possible mirrors in the future when can afford)
Anyway, background...
I bought a couple of Safenet 1141 Encryption Cards. They do AES-CBC, not AES-XLT.
I got the safe.ko from the same Freebsd software level and got it to say hardware encryption in freenas, but with read and sometimes write error 22. I buggered around for about 2 months in CLI could migrate the ZFS to GUI, but it would drop out next boot and i never got rid of the errors when accessing the drive. The drives is healthy when I set it up with GUI. That isn't the problem. I know that is a separate issue when going from CLI to GUI. Anyhow, I gave up on that because coming from CLI to GUI doesn't seem to be stable and I have read so in these forums. I am using XLT and it doesn't seem to take much load off the system, so I have just been using that and for the last week I have been migrating files onto the newly created GUI setup (why fight the ease of setup in GUI when there is little system load ie. I can stream video from this even when copying to and from the same drive with no video degradation/stream quality/speed).
My Question is:
What are these errors reported by crypto? (I have read up about boot via bios vs uefi (I am using bios-MB only support ATM). Do these errors come about from using 16bit code...)
I believe if I could eliminate them, I could use hardware.
I have also read reviews on x5570 vs like E series with AES-NI, and apparently x5570 performs AES instruction faster than the E series in a benchmark surprisingly.
Do I quit on the PCI card and rely on the pair of x5570 to do the AES seeing as though this duel core seems to handle software encryption/decryption well (I have read about system loads from 20% up to 'I can't use the system')?
I guess my number 1 priority question would be take out the card? and just use the system as it is designed?
Sorry for the length of this spiel. I have read lots of forum stuff and a lot of people seem to get hit first up for too little info, system, etc....And I have been drinking...It's Christmas! I'm allowed.
Oh, P.S. My understanding of Linux CLI and commanding is kind of like understanding a language, but not being able to speak it (I can read it and can follow what it is going to do, I am very limited in creating my own commanding (Half and half cut and paste user). I suppose this sytem is GUI, so CLI doesn't matter, but I already typed all that stuff. I'm not wiping it out.

 

[m0nkey_]

I think you're over thinking this.

You're asking to introduce hardware and a kernel module not supported by FreeNAS.

Pool encryption should only be considered if required by law or company policy. If you have important files you'd like to keep reasonably safe, then consider VeraCrypt containers.

The recovery process for an encrypted pool is already complicated enough, what you're proposing is making it even more difficult for yourself.

 

[cr6zed]

Oh. I hadn't considered recovery complications....and that has also got me thinking about encryption/decryption and read/write errors of hardware that isn't working. May as well not use ECC if I plan to use hardware that brings about errors and use a bad dimm instead. No point if the crypto is badly written on the hdd. The RAM ECC won't pick that up, I wouldn't think. I'll just get a screen full of errors and bad data.
Thanks for the insight. I had kind of given up on the pci card, but wondered whether it was worth persuing in the future. I can see that it is not worth corrupt data or a deadpool (lol love that guy).
If I take anything away from this, it would be that this whole system is to keep and store data intact. I am glad it hasn't taken a loss of that to learn.

 

[Chris Moore]

Do I quit on the PCI card and rely on the pair of x5570 to do the AES seeing as though this duel core seems to handle software encryption/decryption well (I have read about system loads from 20% up to 'I can't use the system')?
I guess my number 1 priority question would be take out the card? and just use the system as it is designed?

My question would be, why do you need encryption? I have AES built into my CPU and I don't use it because of the hazards of data loss that are present when the pool is encrypted.
I encrypted a pool once, just for testing, but I reconfigured that set of disks and don't use encryption now.

PS. You can put your hardware description in your signature.

 

[Arwen]

Another option is to simply encrypt files using one of the various programs out there. I use GnuPG and it works for my use. You can even use it on TAR / Archive files to encrypt multiple files or directory trees. For example, I would not want to keep my bank or credit card statements, (scanned or saved via SSL protected website), on-line unless there was some protection.

At rest encryption does nothing for running security.

 

[cr6zed]

Truecrypt. You can even hide the partition.

 

[cr6zed]

And.... it was all about getting the card to work on a testing system or a designed system for testing. I like to follow things to the end, until they work. Do you think I gave up when someone told me you can't run a native OS inside a VMware inside another OS...challenge accepted and done! I did it and it only took 2 weeks. I think they have a GUI option for that now.

 

[Scorm]

Truecrypt. You can even hide the partition.

TrueCrypt is discontinued and unsafe. Consider switching to VeraCrypt.

 

[cr6zed]

Oh. I was not aware of that, thanks.