Move to cryptonite? Deprecate in favor of cryptonite?

[nwf]

In light of http://tab.snarc.org/posts/haskell/2015-06-02-announcing_cryptonite.html the "crypto-pubkey-types" dependency is not long for the world, so this package should probably move over to the newer cryptonite. That also probably means shucking crypto-api's Crypto.Random in favor of cryptonite API, though I don't believe it's essential.

The core modules (src/Codec/Crypto/RSA/Exceptions.hs and src/Codec/Crypto/RSA/Pure.hs) seem easily enough moved, but the test harness (Test.hs) is a little more involved.

That said, cryptonite packages its own RSA implementation, so perhaps anything relevant from this package should go upstream there and this should be deprecated?

Thanks!

[acw]

I think the better plan will be to simply remove the dependency on crypto-api and make the various libraries self-sufficient, thus providing two unrelated crypto libraries for Haskell.

[TomMD]

The issue with depending on cryptonite, as I've discussed with Vincent in the past, is it strictly less powerful compared to crypto-api's Crypto.Random. For example the cryptonite class API DRG (vs crypto-api CryptoRandomGen) makes no reseeding possible, no additional entropy on request, and leans on exceptions instead of sum types so pure code can't recover from failure.

Other past complaints, such as non-determinism, seem to remain partially. Some issues are resolved but I do see the isProbablyPrime function is actually unsafe / nondeterministic. similarly, I wonder what happens if you CBC encrypt something using an incorrectly sized IV - is it still non-deterministic? The types provide no method for failure other than exceptions and the behavior of the prior package makes me suspicious.

WRT RSA in particular, it might be beneficial to simply accept a parameter that can provide a random value, be it by building over a MonadRandom m style type constraint or some other mechanism encoding a generator API. This avoids tying to any one framework but can lead to more crufty API too - yay for me not being Adam and letting him decide on this one.

EDIT: I see IVs now have smart constructors much how crypto-api has done things, so one should not be able to abuse IVs and CBC like in the past. This makes me much more comfortable.

[dbaynard]

How about just replacing the crypto-pubkey-types dependency with one on cryptonite? The most recent x509 package imports the lattter, so the PublicKey data types from each are not compatible, despite being isomorphic.

(Unless there’s another way to import a public key from an external resource.)

[acw]

'''cryptonite''' already includes an RSA implementation, so depending on it for the types seems weird.

That being said, I'm currently in the process of experimenting with translating a bunch of my existing code to cryptonite. If it turns out that it all goes smoothly, and I don't discover anything I disagree with too much or a missing piece I need, I'm actually leaning towards deprecating this package in favor of '''cryptonite'''.

[dbaynard]

It does seem weird. I missed the existing implementation as the cryptonite docs aren’t on hackage.

Thanks!