|| ||Jari Ruusu <jariruusu-AT-users.sourceforge.net>|
|| ||Jim Faulkner <jfaulkne-AT-ccs.neu.edu>|
|| ||Re: PROBLEM: AES cryptoloop corruption under recent -mm kernels|
|| ||Thu, 15 Jan 2004 22:33:25 +0200|
|| ||James Morris <jmorris-AT-redhat.com>, linux-kernel-AT-vger.kernel.org|
Jim Faulkner wrote:
> Could you give me more information about this back-door, and generally
> speaking how it would be exploited? I want to be sure that I am affected
> by this problem.
Kerneli.org 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. Mainline linux
implementation is equally vulnerable.
Most, if not all, file systems have known plaintext. 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. When encryption key setup does not include seed, there will
be direct connection from password to ciphertext. The problem is that these
ciphertexts can be precomputed in advance, and if the database is kept
sorted by ciphertext value, optimized attack is reduced to doing binary
search of precomputed ciphertext values.
You can display precomputed ciphertext with command like this:
dd if=/dev/hda999 bs=16 skip=96 count=1 2>/dev/null | od -An -tx1 -
Here are some samples using AES256 encryption and RIPE-MD160 password hash
function, no seed, no key iteration:
precomputed ciphertext silly password
Of course different ciphers, different key lengths and different password
hashes are going to need separate databases as precomputed ciphertects will
be different if key is set up differently.
> Also, in the loop-AES.README, this is mentioned:
> "Device backed loop device can be used with journaling file systems as
> device backed loops guarantee that writes reach disk platters in
> order required by journaling file system (write caching must be disabled
> on the disk drive, of course)"
> Are you talking about the "hdparm -W" flag for IDE drives?
If you don't have UPS powered box, disabling write caching of disks is
recommended when using journaling file system.
> Would I need
> to disable write caching when using non-journaling file systems?
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)