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: Wed, 26 Aug 2015 12:29:13 +0000 (UTC)	[thread overview]
Message-ID: <loom.20150826T140421-25@post.gmane.org> (raw)
In-Reply-To: 20150822100408.GC7218@yeono.kjorling.se

Michael Kjörling <michael@...> writes:

> 
> On 22 Aug 2015 03:38 +0000, from wurzelsepp1337 <at> web.de (Heinz):
> > 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.
> 
> This holds only if a full SHA-1 hash computation can be reduced to a
> single floating-point operation, which it cannot; hashing a 64-byte
> block with SHA-1 takes somewhere around 40,000 integer operations,
> plus any applicable memory accesses. For a back-of-the-envelope
> calculation, add four orders of magnitude to your figure.
> 
> Also, it disregards the key derivation iteration, which adds another
> several orders of magnitude in practice to converting a LUKS
> passphrase into a keyslot key. Add another four or five orders of
> magnitude to your figure.
> 
> So on this hypothetical system that can do 10^42 flops and has similar
> integer performance, your 16 (1.6 × 10^1) days instead become
> something more like 1.6 billion to 16 billion (1.6 × 10^9 to
> 1.6 × 10^10) days.
> 
> To put this in perspective, that's only two orders of magnitude less
> than the time elapsed since the Big Bang (13.798 × 10^9 years or
> 5.04 × 10^12 days).

Thanks for the clarification. Had it probably imagined too easy.
And of course, the setting of iterations is very significant that was
already aware.

> And 10^42 flops isn't even on the horizon as far as computational
> capability is concerned. Some comparison: Wikipedia lists the fastest
> single computer as of mid-2013 as having a floating-point performance
> of 33.86 petaflops (3.386 × 10^16 flops). You'd need some 2.95 × 10^25
> (29,500,000,000,000,000,000,000,000), or something like 10^15 for
> every person on Earth, of those computers to get to 10^42 flops. Again
> Wikipedia claims that supercomputers are expected to reach one exaflop
> (10^18 flops) in 2018; at 10^18 flops, you'd need 10^24 (that's a
> measly 1,000,000,000,000,000,000,000,000) such computers to reach
> 10^42 flops. One manufacturer apparently claims to be able to deliver
> a 17.1 exaflop (1.71 × 10^19 flops) computer in 2020; you'd need
> 5.85 × 10^22 (58,500,000,000,000,000,000,000) such computers to get
> 10^42 flops, and we currently don't even have _one_.

I know that this computing power does not exist, why has the taken as an
example, what would be necessary.
10^42 are 1000000000000000000000000000000000000000000 FLOPS, this is very
impressive against 10^18 in 2020~.
Especially passwords of up to 95^26 complexity would fall quickly in such a
computing power, provided that the full computing power is available and
nothing like PBKDF2 stands in the way.
But certainly we are no longer experiencing a computing power of this kind,
even if it's fascinating what is basically necessary for a computing effort
to crack passwords.

> That's not to say that LUKS is invulnerable, especially in practice.
> It does however make it seem likely that an adversary would pick a
> different attack. It would be much cheaper, and less obvious, to
> install a key logger, or hire some criminals to kidnap and torture
> your family until you give up the passphrase.

Yes, however. Where it would also be particularly important in future to
hide LUKS/dm-crypt encrypted drives, similar to the Hidden Volumes in TrueCrypt.
In order generally to conceal the existence of encrypted data, which must be
first detected.
Personally, i think Truecrypt is less secure than LUKS/dm-crypt, as this
solution has a wiser architecture for me.

  parent reply	other threads:[~2015-08-26 12:29 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
2015-08-22 10:04     ` Michael Kjörling
2015-08-22 14:05       ` Arno Wagner
2015-08-26 12:29       ` Heinz [this message]
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.20150826T140421-25@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