phc-discussions - Re: [PHC] Defensive use of GPUs (Was: A review per day

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]

Date: Wed, 3 Sep 2014 12:58:57 -0400
From: Rich Felker <dalias@...c.org>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Defensive use of GPUs (Was: A review per day - Parallel)

On Wed, Sep 03, 2014 at 09:21:53AM -0400, Bill Cox wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I am going to personally give Parallel a qualified "A" grade, and
> suggest to the judges that Parallel make it to the next round.
> 
> Do we have any graphics experts here who could chime in?
> 
> The competition has no other entry designed to make use of graphics
> accelerators for defensive purposes.  Even our cell phones have
> graphics hardware now days.  It seems crazy not to use these resources
> for defensive purposes.  I would hate to see our only entry in this
> category get dropped from the competition.

Forgive me for being a non-expert in the application of GPUs for
non-graphics (or even graphics) purposes, but how do you reconcile
your "it seems crazy..." with my view that "it seems crazy" for code
that's performing authentication (on behalf of unauthenticated users)
to have access to the GPU, which often requires elevated or full
hardware access privileges on the OS side, and may also expose full
read/write memory access via the GPU? My (naive; I haven't followed it
closely) impression is that this kind of hardware has repeatedly been
found to have security flaws to the point where "it seems crazy" to
use it for much of anything where you don't have full control over the
code and data being sent to it.

Obviously there are various levels of privsep up to and including
putting GPUs on separate boards/busses that have no access to the host
memory and that are fully reset between runs, but what's actually
practical for defenders? Are there viable setups already that would
mitigate the risks to a reasonable level? Or am I just over-estimating
the risks? I think these questions need to be answered (if they
haven't already) before defensive use of GPUs is considered viable.

Rich