search

typelevel / bobcats

Typelevel's very own CryptoKitties!
Apache License 2.0
28 stars 9 forks source link

Scala Native support #179

Closed yilinwei closed 1 year ago

yilinwei commented 1 year ago

Add basic scala native support.

It differs slightly from http4s-crypto since I've tried to stick to evp as much as possible which as far as I can tell is the (current) recommended approach.

Some of the algorithm selection (e.g. random generator for key generation) is not entirely clear to me, but I've gone with the NIST recommendation where I've found it.

yilinwei commented 1 year ago

OK, I just found out about the existence of https://github.com/http4s/http4s-crypto. I'm guessing that there are some plans for this library so I'll close for now?

armanbilge commented 1 year ago

http4s-crypto is an internal, private fork of Bobcats. This is because Bobcats is still unstable and http4s cannot afford to take on an unstable dependency. Ideally, Bobcats should mature and http4s should use it in the future, but I don't have time to work on that lately.

armanbilge commented 1 year ago

It differs slightly from http4s-crypto since I've tried to stick to evp as much as possible which as far as I can tell is the (current) recommended approach.

Do you have a reference for this? I thought I was following recommended approaches for http4s-crypto 😅

yilinwei commented 1 year ago

Yes, that's understandable; the openssl docs are poorly indexed and it took a while for me to find some of the information.

Firstly it was from the migration guide,

OpenSSL has historically provided two sets of APIs for invoking cryptographic algorithms: the "high level" APIs (such as the EVP APIs) and the "low level" APIs. ... All such low level APIs have been deprecated. You may still use them in your applications, but you may start to see deprecation warnings during compilation (dependent on compiler support for this). Deprecated APIs may be removed from future versions of OpenSSL so you are strongly encouraged to update your code to use the high level APIs instead.

So I think that anything with an EVP prefix is recommended in general.

On the specific cases, you use the HMAC_ and the RAND_ API's.

For HMAC_ I saw that it was not explicitly mentioned in here, but CMAC_ was deprecated, and it recommends the use of EVP_HMAC as a replacement. I also found something in the documentation along the lines of this stackoverflow post saying that the HMAC_ functions aren't hardware accelerated, but I can't find it now again FML.

For RAND_, it is mentioned explicitly, though not the specific function we are using, but at that point I thought it would be prudent to just switch over.

The new EVP_RAND(3) is a partial replacement: the DRBG callback framework is absent. The RAND_DRBG API did not fit well into the new provider concept as implemented by EVP_RAND and EVP_RAND_CTX.