[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK9dnSx3mDFfUGm=97cT8+FG8N7qROgC1Zr2oLxqnpvvkxAqEw@mail.gmail.com>
Date: Thu, 11 Sep 2014 14:44:17 +0200
From: CodesInChaos <codesinchaos@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Makwa is broken given p and q
On Thu, Sep 11, 2014 at 12:53 PM, Bill Cox <waywardgeek@...hershed.org> wrote:
> However, what's to keep all the major online companies from being
> NSL-ed with demands to hand over p and q to the government before they
> are scrubbed from memory? Makwa is a dream come true for Big Brother
> governments.
What keeps them from being forced to store an asymmetrically encrypted
password alongside the hash? For typical centralized providers where
you need to trust the provider anyways, this isn't an additional
problem. In the current state of the internet, this is unfortunately
the vast majority of services.
Note that it's not just the escrow that causes these problems, but the
fast path alone is enough.
The need for trusted key setup is a problem for decentralized
applications. This is also problematic for applications where the same
password is used to authenticate to a server and to do client side
encryption.
Makwa shares this problem with ZeroCoin, which uses a composite
modulus in its accumulator. I believe the ZeroCoin developers work on
creating RSA moduli via secure multi party computation. Not sure how
likely it is to get that to work, but if they do makwa will profit
from that as well.
I think Makwa would work pretty well in most traditional scenarios,
but it causes problems for several scenarios I care about, which is a
bit sad, since they could profit from delegation otherwise
Powered by blists - more mailing lists