User: Password:
Subscribe / Log in / New account

A weak cryptoloop implementation in Linux?

A weak cryptoloop implementation in Linux?

Posted Jan 22, 2004 8:32 UTC (Thu) by error27 (subscriber, #8346)
Parent article: A weak cryptoloop implementation in Linux?

> loop crypto implementation (and derived versions such as
> Debian, SuSE and others) are vulnerable to optimized dictionary attacks
> because they use unseeded (unsalted) and uniterated key setup.

This is a flaw, but it's not a back-door. "Back-door" implies malice and deliberate deceit. It's a bad word to use unless you want to offend someone.

The article explains salting, but the other part of the solution is in the "uniterated". Basically, you take the password and the salt and you hash them. Take that hash and hash it. Repeat the process as many times as you can in .2 seconds. Save the salt and the number of times you hashed the password and salt so you can check the password later.

If you use a 128 bit salt the attacker can't use a dictionary attack directly, but he can still test thousands of possible passwords in a second. With the extra hash iterations the attacker can only test 5 possible passwords in a second.

(Log in to post comments)

A weak cryptoloop implementation in Linux?

Posted Jan 22, 2004 16:23 UTC (Thu) by freethinker (guest, #4397) [Link]

Well, multiplied by the number of processors and cycles the attacker has, with their large budget, compared to the number you have, with your single machine. But it's still a good idea, as long as the hash algorithm doesn't tend to converge or something.

In any case, while salt is good and should be used in any implementation, real security comes from a good passphrase.

A weak cryptoloop implementation in Linux?

Posted Feb 24, 2004 21:38 UTC (Tue) by quantus (guest, #19763) [Link]

Wouldn't aplying an offset to losetup significanly increase the dificulty of finding the location of
the encrypted "plain" text of which to launch the dictionary attack?

>On popular file systems
>such as ext2, ext3, reiserfs and not so popular minix, first 16 bytes of
>fourth 512 byte sector is such good known plaintext. Byte offset 0x600 to
>0x60F of plaintext contain all zero bits. File system itself does not use
>that data at all, but mkfs for file system in question puts that known
>plaintext there.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds