phc-discussions - Re: [PHC] How to: A super-efficient cryptographic accumulator?

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>] [day] [month] [year] [list]

Message-ID: <CADPMZDBja=y1cUy+YPN4CYf6kOL_zRg=hou06BsANYAJVO66vA@mail.gmail.com>
Date: Tue, 13 Mar 2018 04:47:16 -0500
From: denis bider <denisbider.ietf@...il.com>
To: Poul-Henning Kamp <phk@....freebsd.dk>
Cc: discussions@...sword-hashing.net
Subject: Re: [PHC] How to: A super-efficient cryptographic accumulator?

Well, forget the hash function. It can be mod N arithmetic, or an elliptic
curve. It can be a neural network.

To know this can't work, the following question has to be answered:

What is the expected size of a function F(x) => word32, which returns a
value of 0 for N predetermined inputs, and a pseudo-random value 0...2^32-1
for all other inputs not among the N predetermined inputs?

Using the hash function construction, the expected size of F(x) would be
32*N bits.

But are we certain that there is no more efficient construction?

On Tue, Mar 13, 2018 at 4:36 AM, Poul-Henning Kamp <phk@....freebsd.dk>
wrote:

> --------
> In message <CADPMZDDRg45=Wmq7ENf97w=kSHt=Wik5s8S3bG-qm+9Zd_hrHw@...l.
> gmail.com>, denis bider writ
> es:
>
> >Yeah, but... I'm *still* not so sure. :)
>
> Well, let me know when your infinitely fast computer has tried out the
> vastly larger number of different combinations you need to check.
>
> In the meantime ... don't waste too much time on it.
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@...eBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>

Content of type "text/html" skipped