phc-discussions - Re: [PHC] Why protect against side channel attacks

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOow+k-bHXc4j4faiwBzqsnr409g-hU8jhkXU+O+PPHrds1+QA@mail.gmail.com>
Date: Wed, 24 Jun 2015 23:53:52 -0400
From: Peregrine <peregrinebf@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Why protect against side channel attacks

The only way to prevent users from picking bad passwords is to pick
memorable but secure passwords for them. Something like Diceware. Of
course that will annoy users. So it's certainly not a perfect
solution, but it's the only way to prevent the clever idiot from
finding a way to get a bad password past the strength ruleset. It also
has the advantage that you know the entropy of the passwords, so it's
easier to tune the defenses appropriately. If only it weren't
completely unusuable with real users!

On Wed, Jun 24, 2015 at 10:33 PM, Peter Maxwell <peter@...icient.co.uk> wrote:
>
>
> On 25 June 2015 at 02:45, Marsh Ray <maray@...rosoft.com> wrote:
>>
>>
>>
>> I don’t recall if the PHC analysis considered this question explicitly for
>> those functions with password-derived access patterns.
>>
>>
>>
>> It’s probably a moot point for a couple of reasons:
>>
>> * It doesn’t sound like we’re actually contemplating a function with a
>> password-derived access pattern side channel, and
>
>
> Are there any candidates that use the password, or password derived data, at
> any point to derive the memory access pattern?  For example, does the
> password get mixed-in in any way and then the result used to determine the
> memory access pattern?
>
> If the memory access pattern is completely invariant of the password then I
> don't see a problem.
>
>