Geli with passphrase as key?

fgordon · #1 March 29th, 2010, 08:08

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

(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

.....

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?

graudeejs · #2 June 15th, 2010, 17:44

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

fgordon · #3 June 16th, 2010, 07:15

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

big_girl · #4 June 21st, 2010, 19:34

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.

graudeejs · #5 June 21st, 2010, 20:32

So, why not to use paraphrase without key then?
Nobody is forcing you to use key

fgordon · #6 June 22nd, 2010, 07:15

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 -

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"

mix_room · #7 June 22nd, 2010, 09:24

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.

graudeejs · #8 June 22nd, 2010, 09:36

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

big_girl · #9 June 22nd, 2010, 18:12

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.

fgordon · #10 June 23rd, 2010, 08:09

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

graudeejs · #11 June 23rd, 2010, 09:08

Quote:

Originally Posted by big_girl

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.

http://news.electricalchemy.net/2009...-in-cloud.html
and dont miss the next page: http://news.electricalchemy.net/2009...ud-part-5.html

mix_room · #12 June 23rd, 2010, 12:11

Quote:

Originally Posted by big_girl

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).

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.

Quote:

social engineering is way cheaper.

http://xkcd.com/538/

fgordon · #13 June 23rd, 2010, 16:45

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.

big_girl · #14 June 23rd, 2010, 16:53

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?

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Solved] Synaptics - touchpad right key on R60	Oberon	Mobile Computing	15	January 13th, 2010 00:36
Encrypted root, geli password at boot; enter key never released	tcn	General	2	November 30th, 2009 03:41
[Solved] GELI encryption key generation	reenigne	Userland Programming & Scripting	1	September 3rd, 2009 13:51
How to identify passphrase-less ssh-keys?	honk	Web & Network Services	3	August 4th, 2009 14:42
public key	hirohitosan	Web & Network Services	1	April 6th, 2009 07:29

The Following User Says Thank You to graudeejs For This Useful Post:
richardpl (June 23rd, 2010)