Re: question regarding Sha1 and 512 bit key xts mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt




[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux