[dm-crypt] New Luks Format Specification (1.3)

[dm-crypt] New Luks Format Specification (1.3)

[Philipp Deppenwiese]

Hi,

i am Zaolin from the German hackerspace "Das Labor".
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.
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.
If someone sends me the *.tex file of the luks specification, i will update and post it for review.


Regards Zaolin

P.S. Sorry for my poor English.

Re: [dm-crypt] New Luks Format Specification (1.3)

[Arno Wagner]

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 

Re: [dm-crypt] New Luks Format Specification (1.3)

[Milan Broz]

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