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
| ||
|
Message-ID: <CAAS2fgQtvR32K7PZF1V6dRPQib3UyyevGRdyCkWdCbdMierwpQ@mail.gmail.com> Date: Mon, 13 Apr 2015 21:19:59 +0000 From: Gregory Maxwell <gmaxwell@...il.com> To: discussions@...sword-hashing.net Subject: Re: [PHC] winner selection On Mon, Apr 13, 2015 at 9:17 PM, Thomas Pornin <pornin@...et.org> wrote: > On Mon, Apr 13, 2015 at 03:35:42PM +0000, Gregory Maxwell wrote: >> If I'd offered a Makwa competitor it would have had information >> theoretic security for delegation (in exchange for making some >> tricks/performance worse). > > Actually you can. The _definition_ of Makwa is not tied to a specific > delegation mechanism. > > Last December, we were discussing these issues in this list with Adam > Back, and he pointed out a method which offered information theoretic > security for delegation. The method described in the Makwa specification > (and implemented in the reference code) is not information-theoretic > secure, but it is also about 12 times faster, which is why I chose it. > > However, the beauty of the thing, and the important point here, is that > _both_ methods can be applied to Makwa as it is defined; it is merely an > implementation issue. The function itself, and already computed hashes, > are not impacted in any way by the delegation method you choose. > > (I should make an update to the reference code and specification to > include that alternate delegation method. I'll see if I can free up > some time for that job next week-end.) Then I retract! I'd missed that.
Powered by blists - more mailing lists