lists.openwall.net  lists / announce owlusers owldev johnusers johndev passwdqcusers yescrypt popa3dusers / osssecurity kernelhardening musl sabotage tlsify passwords / cryptdev xvendor / Bugtraq FullDisclosure linuxkernel linuxnetdev linuxext4 linuxhardening PHC  
Open Source and information security mailing list archives
 

Date: Mon, 25 Aug 2014 20:13:41 0400
From: Bo Zhu <bo.zhu@...terloo.ca>
To: "discussions@...swordhashing.net" <discussions@...swordhashing.net>
Subject: Re: [PHC] Pleco and Plectron  two provably secure password hashing algorithms
Hi Samuel,
Thank you for pointing out these alternative methods!
They are very interesting and useful. I didn't know them before.
Best,
Bo
On Mon, Aug 25, 2014 at 7:55 PM, Samuel Neves <sneves@....uc.pt> wrote:
> On 08/25/2014 04:27 PM, Bo Zhu wrote:
> >  Can use unfactored Mersenne composite numbers rather than RSA moduli
> > in Rabin in order to
> >  speed up internal timeconsuming steps
> >  use the password hashing algorithms in cryptocurrencies for
> > proofofwork/space.
>
> Using unfactored Mersenne numbers, as described in the paper, does not
> seem to be optimal:
>
>  Mersenne numbers factor much faster than randomlyselected numbers,
> using the special number field sieve (e.g.,
> 2^10391 was factored, in 2007, at a much lower cost than RSA768 [1]); a
> reasonable rule of thumb is that using such
> special numbers requires doubling the modulus bitsize to maintain
> comparable security.
>
>  We don't know how many nor how unbalanced the factors of, e.g., 2^1277
>  1 are, since its factorization is unknown.
> It may well be that one of the factors is significantly smaller than the
> others, which makes ECM the prime choice to
> factor this modulus. This means that we don't actually know how hard it is
> to actually factor this number. Note that the
> factorizations of Mersenne numbers are mostly a hobby project with a small
> number of contributors; it's hard to estimate
> how much computational power has been put into factoring these numbers.
> This does not seem to be a good basis for the
> security of a scheme.
>
> There are alternative methods to generate (much larger) moduli without a
> known factorization [2, 3]. Using some seeding
> material derived from the user and salt (or some nothingupmysleeve
> constant if generation is a bottleneck), for
> example, one can use a pseudorandom bitstream (e.g., Keccak's output) to
> generate a number which is very likely to be
> hard to factor by either ECM or NFS.
>
> [1] https://eprint.iacr.org/2007/205
> [2] http://link.springer.com/chapter/10.1007/9783540479420_21
> [3] http://link.springer.com/chapter/10.1007%2F9783642389801_35
>
Content of type "text/html" skipped
Powered by blists  more mailing lists