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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 17 Dec 2014 18:24:28 +0000
From: Gregory Maxwell <>
Subject: Re: [PHC] Re: Some KDF stumbling blocks, plus Common

On Wed, Dec 17, 2014 at 11:26 AM, Thomas Pornin <> wrote:
> On Wed, Dec 17, 2014 at 09:57:15AM +0800, Ben Harris wrote:
>> A naive question based on my limited knowledge of cool terms like abelian
>> groups - if you did this using elliptic curves could you not worry about
>> the security of pq? And just suffer the once off work to calculate y. Or
>> does the math not carry over to elliptic curves?
> The math does not carry over to elliptic curves (or, at least, I did not
> find a way to), unless you do something like generating a curve of order
> n where n = pq with p and q unknown (in which case you gained nothing).

Class groups in imaginary quadratic number fields can give you a group
where the counting the order is presumed hard.
( )

Sort of gone far afield for the list, sorry about that.

In any case, for some applications the potential of a trapdoor is
fine. ... e.g. if the trapdoor is per service and this system is just
used to authenticate to the service, I see no great concern.

When talking about parameters to be shared by the general public, I am
dubious that any amount of ritual is really sufficient:  Especially
since a good cryptosystem must be able to strongly reject conspiracy
theories that attackers could use to social engineer users out of
using strong cryptographic tools in the first place.

Powered by blists - more mailing lists