lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 29 May 2015 16:03:50 -0400
From:	Theodore Ts'o <>
To:	Dmitry Monakhov <>
Cc:	Ext4 Developers List <>,, Ildar Muslukhov <>
Subject: Re: [PATCH-v2 08/20] ext4 crypto: add encryption key management

On Fri, May 29, 2015 at 08:55:17PM +0300, Dmitry Monakhov wrote:

> This gives me as an attacker very good guess that
> l51q60ZbBvtGnUl8a3y3yA == grep and so on, So I have can try brute force
> attack on first block (But AFAIU it is not practical for AES-256)
> May be we can prevent this my tweak inode size if key is not
> available. For example allign i_size to fsblock which makes distro-based
> attack impractical. See patch attached.

It's not practical for AES-128, let alone AES-256:

     If you assume:
        * Every person on the planet owns 10 computers.
        * There are 7 billion people on the planet.
        * Each of these computers can test 1 billion key combinations per second.
        * On average, you can crack the key after testing 50% of the possibilities.

     Then the earth's population can crack one AES-128 encryption key in
     77,000,000,000,000,000,000,000,000 years![1]

AES-256 is 10^19 times harder.  So take the
77,000,000,000,000,000,000,000,000 years and add another 19 zero's.

The bottom line is trying to deny the attacker plaintext/ciphertext
pairs really isn't worth the effort.  It's assumed the attacker can do
this, and it really doesn't bother me.  After all, the the per-inode
key is a completely random 256 bit key.

The much more concerning attack is one where the attacker tries to
attack the user's passphrase by trying brute force the user's
password.  We're using a pbkdf2_sha512 with an iteration count of
65535, to try and slow down the brute force attack, but if the user is
using the typically horrendous user-chosen password, it's still going
to be the weakest link.

So the attacker will simply use a password link, try all lower-case
passwords, all lower case passwords with a single digit, etc., etc.,
turn that into a master key, try to use the master key and the nonce
to create the per-inode key, and then see if the resulting file or
filename looks plausible.  The fact that it will take 65535 iterations
of SHA-512 per passphrase tried will slow the attacker down somewhat,
but if the user uses a birthday, or their girlfriend's name, etc.,
it's not going to help enough.

> At least it would be reasonable to provide this as an mkfs/tune2fs
> option.

I'd really rather not support adding extra complexity unless it's very
clear what is the specific threat that we are protecting about, and
we're clear that it is a valid threat in the context of the overall
system.  Otherwise we may be strengthening the titanium/steel door
while ignoring the paper maiche walls that it is set in.

(Or see the image on slide #4 of:  :-)

						- Ted

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists