linux-ext4 - Re: [PATCH-v2 08/20] ext4 crypto: add encryption key management facilities

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <20150529200350.GG18540@thunk.org>
Date:	Fri, 29 May 2015 16:03:50 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Dmitry Monakhov <dmonlist@...il.com>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	mhalcrow@...gle.com, Ildar Muslukhov <muslukhovi@...il.com>
Subject: Re: [PATCH-v2 08/20] ext4 crypto: add encryption key management
 facilities

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:
http://kernsec.org/files/lss2014/Halcrow_EXT4_Encryption.pdf  :-)

						- Ted

[1] http://www.eetimes.com/document.asp?doc_id=1279619
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html