All of 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.