* Re: [dm-crypt] New Luks Format Specification (1.3)
2012-02-01 7:59 [dm-crypt] New Luks Format Specification (1.3) Philipp Deppenwiese
@ 2012-02-01 8:19 ` Arno Wagner
2012-02-01 9:23 ` Milan Broz
1 sibling, 0 replies; 3+ messages in thread
From: Arno Wagner @ 2012-02-01 8:19 UTC (permalink / raw)
To: dm-crypt
Hi Zaolin,
On Wed, Feb 01, 2012 at 08:59:10AM +0100, Philipp Deppenwiese wrote:
> Hi,
>
> i am Zaolin from the German hackerspace "Das Labor".
Never heard of it, sorry.
> The last month I concentrated on how to change the luks specification to
> be state of the art. Up to now we still use SHA-1 as default algorithm
> for PBKDF2 in luks.
SHA-1 is not a security problem when used in this fashion.
> The next problem is the excessive use of parallel
> bruteforcing systems like ASIC, FPGA or GPUGPU technology. A new key
> derivation function is needed in order to raise the complexity of
> bruteforce attacks against the luks key derivation function.
No, it is not. At the very worst, a higher iteration count may
be needed, but that question involves a trade-off that is
regularly discussed here, see the mailing-list archives.
> If someone
> sends me the *.tex file of the luks specification, i will update and post
> it for review.
I doubt there is need for that. Please post your cryptoanalytic
results here, so that we can have a look. If you are trying
for a large-memory key-derivation function, please note that
a) this was discussed here recently (if I remember correctly,
I do remember that I was in some discussion about it and that
the large-memory property was doubtful at best) and that
b) it is unclear whether a large memory property, if
ensured, will even help.
Also note that against a determined or hogh-ressource attacker,
the only help is a high-entropy passphrase, as has been discussed
on this list several times and is clearly stated in the FAQ.
Arno
--
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
----
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [dm-crypt] New Luks Format Specification (1.3)
2012-02-01 7:59 [dm-crypt] New Luks Format Specification (1.3) Philipp Deppenwiese
2012-02-01 8:19 ` Arno Wagner
@ 2012-02-01 9:23 ` Milan Broz
1 sibling, 0 replies; 3+ messages in thread
From: Milan Broz @ 2012-02-01 9:23 UTC (permalink / raw)
To: Philipp Deppenwiese; +Cc: Liste Cryptsetup
On 02/01/2012 08:59 AM, Philipp Deppenwiese wrote:
> Up to now we still use SHA-1 as default algorithm for PBKDF2
> in luks.
Firstly, thank you for sending to the list where it can be
properly discussed.
For others, I guess this originates in
http://code.google.com/p/cryptsetup/issues/detail?id=119
As you know, SHA1 is not hardcoded anymore, you can use whatever
has algorithm you want and is supported in crypto library.
Arno and others will surely comment here issue of PBKDF2 use.
> The next problem is the excessive use of parallel
> bruteforcing systems like ASIC, FPGA or GPUGPU technology. A new key
> derivation function is needed in order to raise the complexity of
> bruteforce attacks against the luks key derivation function.
This is just your statement, please provide facts supporting it.
> If someone sends me the *.tex file of the luks specification, i will
> update and post it for review.
tex file is in svn. But changing LUKS header definitely doesn't work
this random way.
Please discuss your ideas, provide theoretical background, send a patch
and if there is real problem to solve, I am sure it will become
part of code.
Thanks,
Milan
^ permalink raw reply [flat|nested] 3+ messages in thread