[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ9ii1G2yFGd-rMnsorxpXjJ_S1bDBMZhuuS0zTwfxupQm6nLA@mail.gmail.com>
Date: Wed, 29 Jan 2014 16:56:11 -0500
From: Matt Weir <cweir@...edu>
To: "john-users@...ts.openwall.com" <john-users@...ts.openwall.com>
Subject: Re: Honey Encryption
First off, for full disclosure I've talked with Ari about this in the past
but I have no idea what shape the current solution they are proposing is.
So take everything I say with a grain of salt.
While as a defender you could simply have multiple password vaults, (like
how magnum mentioned with Truecrypt), there's a lot of potential issues
with that. Some of the bigger issues are that it limits the number of
"fakes" you can have due to size required to store them, and the fact that
you may periodically want to regenerate your fakes as your password vault
grows since A)You don't have the password that the fakes were originally
created with, and B) You may want the fakes to be approximately the same
size as your real password vault. I know, password strings are small and
disks are big, but still such a honeyvault approach requires a large amount
of false positives since there's so many sites in the vault an attacker can
use to verify passwords, some of which are bound to not rate limit log in
attempts.
So another approach would be to have your master password instead work like
an indexing function vs using it to decrypt an encrypted file. As a very
basic example of that, consider the index_to_plain function used in rainbow
tables. It takes a random index value and generates a password guess with
it. Now most rainbow tables use a brute force approach for index_to_plain
but you can use whatever password generation technique you want. For
examples of alternate indexing techniques see some of the hybrid tables in
rcracki (same idea as mask mode in hashcat), or the old dictionary based
tables I wrote back in the day
https://sites.google.com/site/reusablesec/Home/rainbow-tables (side note,
that project is also how I got banned from Google Code).
The nice thing about an indexing approach is you really would get a
different set of password vault data for every guess you make. The hard
part is making the resulting values believable enough to appear real when
faced with automated analysis or ideally real humans looking at the
results, (automated analysis is the big one though since the ultimate goal
is to waste an attacker's time and increase the cost to verify if they
obtained the real password vault data). With password vaults you have the
additional problem where not only does the defender have to generate fake
passwords, but they also have to generate a believable list of "fake" sites
associated with those passwords as well. This is because the list of sites
the defender has accounts on is also something you want to hide from the
attacker.
Matt
On Wed, Jan 29, 2014 at 3:55 PM, magnum <john.magnum@...hmail.com> wrote:
> On 2014-01-29 20:47, Rich Rumble wrote:
>
>> http://www.technologyreview.com/news/523746/honey-
>> encryption-will-bamboozle-attackers-with-fake-secrets/
>>
>
> Truecrypt, for example, has had ability to store *one* alternate
> filesystem with *an* alternate passphrase for years. Maybe it can be more
> than one, but very few.
>
> But I really can't see how the *each* in "each incorrect attempt to
> decrypt a vault would yield a fake one instead" would be implemented unless
> it's just smoke and mirrors in the legitimate client (eg. a disk encryption
> program). If you use JtR instead of the legitimate client you'd not be
> fooled so this is just snake oil. Hopefully I'm wrong but then I'd really
> appreciate a technical explanation.
>
>
> I didn't think much of the technique, but I remembered some Zip files
>> (aes256) false positive just like this and I had to re-think my position.
>>
>> If it's combining bcrypt/scrypt "speed" and giving you those FP's then
>> maybe. Again it's encryption not hashing so it's more like the zip example
>> I guess.
>> http://www.openwall.com/lists/john-users/2011/09/21/7
>> I haven't checked a recent version of John out, does AES256 zip still FP?
>>
>
> Yes, and it's frequent enough the format is more or less unusable. It's
> been moved to the broken/ subdirectory for now.
>
> magnum
>
>
>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
