Closed photm5 closed 9 years ago
It takes SHA1 and base32 to calculate the .onion address out of an RSA key, see Tor’s rend-spec.txt, from line 526.
See https://hackage.haskell.org/package/cryptonite for a collection of crypto primitives (all pure and portable).
I'd use https://hackage.haskell.org/package/crypto-random for secure randomness. Do not (!) use https://hackage.haskell.org/package/random. It's not cryptographically secure.
Thanks for the suggestions.
Here's something more specific. I think it also does the ASN1/DER encoding. All libraries by Vincent Hanquez are usually well mantained.
https://hackage.haskell.org/package/cryptocipher-0.3.0/docs/Crypto-Cipher-RSA.html#t:HashASN1
In On the state of cryptography in Haskell, crypto-random
is mentioned as an example of how to do it wrong. (And Vincent Hanquez also gets a negative mention.) But I didn’t investigate myself, so I cannot be sure whom to believe. I just want to tell everyone who reads this to be careful when choosing crypto libraries.
What about saltine? It seems to be based on NaCl and libsodium, which seem pretty good.
It looks like saltine or HsOpenSSl are good choices.
For random numbers why not Just use urandom? (Which would be a simple library)
Using /dev/urandom
would cost us Windows compatability, but I don't think that's much of a concern for any of us. :new_moon_with_face:
Windows compatibility would be a good thing to have.
I’d propose using /dev/urandom
when available, and crypto-random
on Windows. The RNG issue cannot be solved on Windows anyways, as we don’t know if Microsoft just reads the numbers out of our memory.
This is a decent idea but how do we implement it?
System.Directory.doesFileExist
?
I didn’t find everything we need in saltine, so I guess we’ll want to use HsOpenSSL. (Assuming we want to stick to the ones @lukasepple proposed.) I wouldn’t decide in favor of cryptonite because its haddock page says it’s experimental (And we heard some bad things about its author), while HsOpenSSL calls itself stable (Which seems reasonable, as they’re just a binding to a commonly used library.)
What does everyone in @Jugendhackt/ricochet think?
Sounds good to me. What's missing from saltine, though?
The only thing it has from the above list is HMAC-SHA256
and maybe a good entropy source. The signing it provides uses elliptic curves.
I am unhappy with HsOpenSSL still since it is a binding to OpenSSL and OpenSSL isn't the greatest piece of software either.
I think OpenSSL is getting better, since everyone knows how bad things can go wrong. In my opinion, the worst part about OpenSSL is its ugly interface that is easier to use wrong than to use right. Since we don’t use it directly, we’re not exposed to the problem as much. In addition, HsOpenSSL seems to only expose the higher-level part of the API. (However, I didn’t look at the HsOpenSSL API in much depth yet.) Do you share my opinion, or is it something else that worries you? Did you find any alternatives that are better?
Actually it seems like using HsOpenSSL is the only option at the moment.
We should stick with it as long as we need to and then replace it.
It seems we all agree on using HsOpenSSL (even though it’s not perfect), so the issue of finding a crypto library is solved.
We should stick with it as long as we need to and then replace it.
Sounds like a good idea, do you propose to write our own wrapper module?
I forgot to mention: We also agreed on using /dev/urandom
in case the file
exists, downgrading to crypto-random
if necessary.
Sounds like a good idea, do you propose to write our own wrapper module?
Good Idea. Network.Ricochet.Crypto
We need to find a crypto library with haskell bindings (or create/improve bindings to a good crypto library ourselves), in order to implement some parts of the protocol. See AuthHiddenService. We need:
See On the state of cryptography in Haskell.