DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Heinz <wurzelsepp1337@web.de>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode
Date: Sat, 22 Aug 2015 03:38:16 +0000 (UTC)	[thread overview]
Message-ID: <loom.20150822T042840-431@post.gmane.org> (raw)
In-Reply-To: 20131211180419.GA13829@tansi.org

Arno Wagner <arno@...> writes:

> No, that is not the statement. The statement is that collision attacks
> (the SHA1-weakness) are irrelevant for password hasing.

Or in other words, SHA1 is secure in this case. But why not always use the
best possible hash algorithm, instead of an option which is at least safe?
I would logically use always the strongest one, purely as a precaution, and
not what has already demonstrated weaknesses of any kind. I would not want
to wait if SHA1 really holds a long time. :)
 
> 2^160 is about 1.5*10^48. The number of atoms in this planet
> is only 1.33*10^50. So if you can convert the whole planet to 
> storage space and can store one bit in one atom, you can just 
> about do it. Then there is the computing effort: Say, you get 
> 1M hashes/sec with 1W of power. As PBKDF2 runs with around 
> 100'000 iterations on average PC hardware, you then get 1
> iterated hashe for 0.1 Joule of power. That means for 2^160
> of them, you need 150*10^45 Joules. The sun has an energy
> output of 3.8*10^26 W. So run the sun for 384*10^18 seconds =
> 12.8*10^12 years and you have your table.
> 
> Sounds pretty unrealistig, right?

Yes, but for me a very original presentation.

If i am not mistaken, a computing power of at least 10^42 FLOPS would be
needed to effectively go through this area.
2^160 / 10^42 FLOPS = 1461501 Seconds = 16 Days to break SHA1, but
technically we arrive until approximately 10^18 FLOPS or 1 exaFLOP.

> Also note that your password is unlikely to even have 100 bits
> of entropy. If you actually use a passwored with more than
> 160 bits of entropy, moving to SHA-256 as hash function may 
> provide an irrelevant security improvement.

All over 128 bits is really overkill.

I once extracted my masterkey and wonder, why this consists only of numbers
and the letters a-f?
Why not a-z/A-Z? And special characters?
Okay respect brute-force attacks is a key space of 16^128 in fact
impossible, but why not exploit the maximum of what is possible? :)

  reply	other threads:[~2015-08-22  3:50 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-11 16:31 [dm-crypt] question regarding Sha1 and 512 bit key xts mode anderson jackson
2013-12-11 18:04 ` Arno Wagner
2015-08-22  3:38   ` Heinz [this message]
2015-08-22 10:04     ` Michael Kjörling
2015-08-22 14:05       ` Arno Wagner
2015-08-26 12:29       ` Heinz
2015-08-22 13:58     ` Arno Wagner
2015-08-26 12:51       ` Heinz
2015-08-23 18:51     ` Sven Eschenberg
2015-08-23 19:38       ` Arno Wagner
2015-08-23 20:21         ` Sven Eschenberg
2015-08-24  6:18           ` Milan Broz
2015-08-24 11:54             ` Arno Wagner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=loom.20150822T042840-431@post.gmane.org \
    --to=wurzelsepp1337@web.de \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox