Geli with passphrase as key?

F

fgordon

As I'm planning to use zfs / geli combination on a raid z2 with 12 harddisks I don't really want to enter the passphrase 12 times :D (it's no 24/7 server)

So I'm planning to use the passphrase as key - I know that I need a reasonably long passphrase (50+)

my idea is at the moment

echo $pwd|geli attach -p -k - /dev/ad[x]

after geli init done in the same way of course :D.....

Are there any security related issues - besides having to use a real good passphrase and possible attacks while the script is running - in doing this?
 
Why not to use simple binary key on flash?

Code: 
# dd if=/dev/random of=/mnt/key bs=1024 count=512
# geli init -e aes -l 256 -s 4096 -P -B -K /mnt/key ad0

you'll need little more that code I showed, check geli(8) for more info, how to make this work :)
 
As I don't want to have the key physically stored

Security with a key stored outside the brain is no option as there is always the possibility of the keyfile getting in the wrong hands
 
Yeah, I have the same issue. Entering the pswd each time for each disk in a raid array is a pain, and I also cannot have a physical key stored somewhere. Since the point of my raid array is to store sensitive data in a failsafe way, relying on another physical device to get access not only provides a security problem but also another point of failure.

I only care about protecting the data from prying eyes; not about performance.

I was wondering if there was any risk by using the same password/key file for several geli disks? These disks are all part of the same raid array..

Thanks.
 
As you can see in my first post here in this topic I`m already using

geli attach -p -k - /dev/ad[x]

This was never the question - the only question here still is - and always was - :D does using geli without a key with the same password for multiple drives lowering the security significantly or not - (in combination with a long passphrase)?

The hint to use a passphrase only with an initial question "is using a passphrase only safe with geli....?" *g* does not really help...

As ZFS is missing a crypt (and probably will for some time) till now there is no other possibility then crypting the zfs members on a lower level. With more than 5 or even 10 drives forming a tank inidivdual passwords for each drive are not really nice to use ... heheh or only if you use "password1", "password2" :D :D
 
Store the keys to the 12 drives physically on an encrypted USB-drive, remember the key to the USB-drive.
Then you will only have to enter your passphrase once.
 
well, if you can remember 512K long paraphrase, sure.... go a head....
It will be as good as 512K key....

the paraphrase won't be.
Geli will store only hash of it {I supposed it does the same for keys as well, but i'm not geli engineer}

I think, using passphrase is equally secure as using key, as long as passhprase is long enough (14 characters can be cracked easily)

However best is probably to use both key and pass-phrase :D
 
Dancing around the answers

I'm hesitant to use encrypted USB keys just b/c it adds another point of failure to what is supposed to be a failsafe ZFS array if you lose your keys (I'm not willing to keep 5 USB sticks around just in case).

The pressing issue still remains--

Does using one passphrase for multiple disks (yes, you have to enter it for each disk) compromise security? This may apply regardless of the USB key/passphrase issue (unless you keep a different key for each disk on your USB, which is clearly an advantage to USB sticks over remembering a passphrase if sharing a key across multiple disks lowers security).

And regarding a 14 character passphrase, given that there are 26 letters on your keyboard, each has upper and lowercase, plus 10 numbers, then there's a bunch of other symbols, you've got maybe 80 possible choices for each of the 14 characters. Guessing by chance (brute force) leaves your problem as "80 choose 14" which has more than 10^15 possibilities. Love to see that get cracked...social engineering is way cheaper. :)
 
I hope ZFS will implement crypt soon, though this seems to be an "endless" project - this is the only disadvantage for me of having "raid" inside of zfs you cannot have a crypt layer between the software raid and the filesystem.....

Hehe but then.... a perfect system would be boring too :D
 
big_girl said:
And regarding a 14 character passphrase, given that there are 26 letters on your keyboard, each has upper and lowercase, plus 10 numbers, then there's a bunch of other symbols, you've got maybe 80 possible choices for each of the 14 characters. Guessing by chance (brute force) leaves your problem as "80 choose 14" which has more than 10^15 possibilities. Love to see that get cracked...social engineering is way cheaper. :)
Click to expand...

http://news.electricalchemy.net/2009/10/cracking-passwords-in-cloud.html
and dont miss the next page: http://news.electricalchemy.net/2009/10/password-cracking-in-cloud-part-5.html
 
big_girl said:
I'm hesitant to use encrypted USB keys just b/c it adds another point of failure to what is supposed to be a failsafe ZFS array if you lose your keys (I'm not willing to keep 5 USB sticks around just in case).
Click to expand...
Print it out and place it in a sufficiently secure location. You will have the same problem with your passphrase aswell, forget that and you are screwed.

social engineering is way cheaper. :)
Click to expand...
http://xkcd.com/538/
 
You can brute force short passwords and you can do this quite fast with a cloud, but you never will be able to brute force long passwords - as energy is the limitation and energy is limited, because matter is limited in our universe and every command a cpu executes will always need at least a tiny amnount of energy.

Even if you had trillions^trillions^trillions of cpus - you will never be able to brute force a long password it`s impossible - at least in our universe.

You can hope the algorithm is not perfect or try dictionary attacks - that`s all there is.
 
I agree, ZFS crypto will likely not become a reality in time for it to be worthwhile, plus geli + ZFS works fine in my hands, so why not work with what is free & available and help it survive & improve.

killasmurf, great, great article - thanks. My favorite quote -- "In this case the hypothetical threshold between doable and not worth it falls at the 11 character password boundary." It's helpful to know how a few characters will improve your security -- if you up your password from 14 to 20 chars, the time to exhaustively search will increase by at least 1,000 fold (3 orders of magnitude). I know amazon and various other groups have clouds, but there's no way to increase the cloud by a factor of 1,000...you just have to wait longer. :)

People should be aware of these things and use longer passwords that are NOT comprised of dictionary words. Even keeping grammatical rules for nonsense words (e.g. a 'q' is always followed by a 'u') will make it a *ton* easier to brute force a password.. that's one limitation of the simulations in that article - the people who are really doing this have heuristic dictionaries & rules that will DRAMATICALLY reduce search time in the case of a non-random password. Hence your best bet is to make them to use brute force by having a truly random key.

The question still remains -- does repeating a password or key for multiple devices (even if I had an encrypted /home directory and maybe a usb removable disk, both sharing a password) make it easier for someone to learn the key?
 
You must log in or register to reply here.
Back
Top