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]

Date: Tue, 13 Mar 2018 05:01:17 -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?

It seems to me the term "fractal compression" used in this thread might not
be the same thing as "fractal compression" discussed in this Wikipedia
article:

https://en.wikipedia.org/wiki/Fractal_compression

The version of "fractal compression" discussed in the article is not
theoretical - it actually works and delivers superior quality at high
compression ratios, but at a significant computational expense.

Is this the concept you refer to with "fractal compression", or do you mean
a different kind?

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

> --------
> In message <CADPMZDBja=y1cUy+YPN4CYf6kOL_zRg=hou06BsANYAJVO66vA@...l.
> gmail.com>, denis bider writ
> es:
>
> >But are we certain that there is no more efficient construction?
>
> That's the entire crux of the fractal compression canard:
>
> Yes, there *might* be such a function, we don't know, and we don't
> even know the proability of it.
>
> What we do know is that the only way to find it, should it exist,
> is bruteforcing a space vastly larger than the number of elementary
> particles in the universe.
>
> Or, as somebody summarized it: "Yes, miracles happen, but don't count 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