Re: Pure Haskell replacement for a dependency package
Hi, Am 2019-02-22 um 13:46 schrieb Mikhail Glushenkov: >Looking closer at eccrypto, I can identify the following issues: > >1) eccrypto has a larger dependency footprint than ed25519, which only >depends on GHC boot libraries >2) ed25519 is much better documented >3) eccrypto is quite new and not as mature as ed25519, which is based >on the reference implementation Regarding those issues, I uploaded a new version of eccrypto with only cryptohash-sha512 as a non-boot dependency. Since hackage-security already depends on cryptohash-sha256 with its low depency footprint, I thought it most prudent to go that route. Of course, the new code is also analysed like the one from last release. Documentation will follow, as well as scientific review. Only the last part - being more mature than the ref10 C code - my code will never be. ;-) >However, I still think that we could accept a patch adding support for >eccrypto as a compile-time option (not enabled by default). I'll also start looking into making a patch for hackage-security for review. Best, Marcel ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Pure Haskell replacement for a dependency package
Hi, On Fri, 22 Feb 2019 at 12:53, Mikhail Glushenkov wrote: > > If it doesn't result in too much of a slowdown, I think it would make > sense to do this change. I'd recommend making the choice between > ed25519/eccrypto configurable via a flag so that we could compare the > two. I'm cc:ing Edsko, who is the main author of hackage-security. Looking closer at eccrypto, I can identify the following issues: 1) eccrypto has a larger dependency footprint than ed25519, which only depends on GHC boot libraries 2) ed25519 is much better documented 3) eccrypto is quite new and not as mature as ed25519, which is based on the reference implementation However, I still think that we could accept a patch adding support for eccrypto as a compile-time option (not enabled by default). ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Pure Haskell replacement for a dependency package
Hello Mikhail, Am 2019-02-22 um 12:53 schrieb Mikhail Glushenkov: >> Would you as developers of hackage-security / Cabal / stack be >> interested in adopting such a replacement? And, if yes, what >> conditions would such a library have to fulfill? > >If it doesn't result in too much of a slowdown, I think it would make >sense to do this change. I'd recommend making the choice between >ed25519/eccrypto configurable via a flag so that we could compare the >two. I'm cc:ing Edsko, who is the main author of hackage-security. That sounds prudent. I included some basic benchmarks and depending on the CPU used I get some triple digit signatures/verifications per second per core (even on Sandy Bridge; only low-hanging fruit optimizations used until now). ed25519 is faster, but I am unsure what your intended performance profile is. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
Re: Pure Haskell replacement for a dependency package
Hi Marcel, On Tue, 19 Feb 2019, 15:43 Marcel Fourné > Hello, > > hackage-security is using the ed25519 package, which in itself is > wrapper library around a C/Assembly implementation. > I have just released a pure Haskell implementation of that (modulo > slightly different API the same signature bytes), without using C bits > other than the well known integer-gmp. Tests and benchmarks are > included, if you want to see those for yourselves, but the proofs for > timing attack security still need to be written up for > scientific publishing. > > Would you as developers of hackage-security / Cabal / stack be > interested in adopting such a replacement? And, if yes, what conditions > would such a library have to fulfill? If it doesn't result in too much of a slowdown, I think it would make sense to do this change. I'd recommend making the choice between ed25519/eccrypto configurable via a flag so that we could compare the two. I'm cc:ing Edsko, who is the main author of hackage-security. ___ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
