Date: Mon, 24 Sep 2007 13:40:17 +0200 (CEST) From: Christian Baer <christian.baer@uni-dortmund.de> To: freebsd-geom@freebsd.org Subject: Re: Pipes password from kdialog to geli attach Message-ID: <fd87n1$2mm5$3@nermal.rz1.convenimus.net> References: <200709222256.17692.yarodin@gmail.com> <20070923152508.GB1123@garage.freebsd.pl> <fd69pu$2ip2$1@nermal.rz1.convenimus.net> <20070924091902.GB3320@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 Sep 2007 11:19:02 +0200 Pawel Jakub Dawidek wrote:
>> > BTW. sha256 is not needed.
>> Could be a good idea though when mounting several providers with one
>> keyfile/passphrase combination - if they are "salted".
> GELI already provides additional salt and pass passphrase/keyfiles
> through HMAC function.
Ok, my bad. I didn't mean the salt provided by geli, but this:
echo "SeCuRE01${password}sEcUre01" | sha256 | geli attach -p -k - /dev/ad0s1e
^^^^^^^^ ^^^^^^^^
The underlined Stuff is the "salt". Not quite politically correct, but I
couldn't really think of anything better to call it.
> It's not about salt. The idea is to call HMAC some number of times on
> the passphrase and use the result. I use 131072 iterations with my
> passphrase, this means that to brute-force my passphrase an attacker
> needs 2^17 more steps to do for each password he wants to try.
> It takes about 2 seconds to calculate the key out of my passphrase
> because of those 2^17 steps.
If I understand you correctly, you are not actually adding more security
to the passphrase but just making sure that each attack ist sufficiently
expensive, meaning each attack takes about two seconds.
How exactly do you do this? IIRC geli doesn't do this by itself.
> He can of course brute-force the result, but it's more or less totally
> random and for HMAC/SHA256 he has 2^256 steps to do.
Well, not really 2^256 steps, just as many as it takes to find the right
one. :-) We have 2^256 combinations but it is pretty unlikely that an
attacker will have to go through all of them to find the correct one.
But let's be optimistic about an attack. Say we need 2^128 of them to find
the right "result" and one attack takes 10ms (which makes 100 tries per
second). Then it would still take
2.589.667.936.993.443.405.352.926.997.197 *years*
to break open the code - if I didn't mess something up on my calculator. :-)
Just as a reference: our universe is estimated to be about
15.000.000.000 years old.
An attacker will have to get *really* lucky or find a weakness in
Rijndael.
> We are planning to create graphic front-end to the GEOM in my company in
> python, but feel free to do a geli front-end as well:)
How concrete are these plans? I don't really think this is something that
competition would help with. Sure, there is always more than one solution
for a problem but this problem isn't really one that is crying out for
several ones.
Are you only planning on doing this "some day in the future"? Do you
already have a roadmap? Is this for all of GEOM, including GELI? I realise
that you can't share the details, I just want to avoid duplicating your
work.
Regards
Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd87n1$2mm5$3>