Re: question regarding Sha1 and 512 bit key xts mode

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

 



On Sat, August 22, 2015 05:38, Heinz wrote:
> 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. :)

Sorry to intervene here. Hashing in LUKS is only used to check if a
password/passphrase is a candidate. So, even if you manage to find a
collision, the worst that can happen is, that LUKS accepts the
'collisison' as valid key and you'll get gibberish on the mapping. Your
encrypted data will be useless 'random' data and is not compromised then.

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


_______________________________________________
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