typelevel / bobcats Goto Github PK

See typelevel/fs2#3157.

Generally my thoughts are that this would be beneficial for Scala native and on the JVM.

As mentioned in the linked issue, the suggestion was to use keypool.

Here are some thoughts:

• We don't really want it to be bounded, as the only issue with creating tons of these objects is just increasing the memory. Waiting for a free member would really suck.
• I suspect that our idle lifetime for our various resources is dependent on the runtime. On scala native, it's pretty much going to be a malloc call so it's going to be fairly cheap - on the JVM, it's going to go through class reflection which is going to be a bit more expensive. Node delegates to OpenSSL so it will be the same as native unless they do something clever under the hood.
• I'd also like to introduce some rudimentary benchmarking to see if it actually makes a difference.

H/t @ChristopherDavenport in Discord

Cypher Suites
TLS_AES_128_GCM_SHA256 - Mandatory
AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

Digital Signatures
rsa_pkcs1_sha256 (for certificates)
rsa_pss_rsae_sha256 (for CertificateVerify and certificates)
ecdsa_secp256r1_sha256

key exchange
secp256r1 (NIST P-256) MUST
X25519

Hi, I am implementing the HTTP Signature RFC from IETF over in this repo httpSig. I am extracting a lib there I wrote to work for Akka so that it can also work with http4s. The IETF spec lists the hashing and signing algorithms in section 3.3 that should be implemented.

For the moment I'd feel most comfortable if RSA worked, as I know that quite well :-)
(see the code SignatureVerifier).

But I don't see any tests for public key signature nor any code Implementing it. Is that something you intend to support soon?

Maybe using memcmp.

Issue to track experiments wrapping the various API's and features already, as a reference point.

• https://github.com/http4s/http4s-crypto
• https://github.com/Dwolla/fs2-pgp
• https://github.com/typelevel/fs2/blob/main/core/js/src/main/scala/fs2/hash.scala
• https://github.com/jwojnowski/fs2-aes

The branch on which PR #48 is located, used the browser dom web crypto API to get going (in order to make the task more manageable). Node JS uses the same Web Crypto API but somewhat differently, and so it seems better to build a local facade as is done for the symmetric keys.

Implementing #52 will likely depend on this.

Implementing more cryptographic algorithms, such as in #51, would help lay the groundwork of tests to help work out what parts of the facade need to be written.

Learning this trick from CE: even if the constraint we request is less than Async, we can check if the instance is Async and replace it with the async crypto implementations which are always better than the sync implementations.

The HTTPbis WG's Signing HTTP Messages RFC team have been looking to add support for Ed25519.

The branch for asymmetric keys #48 allows them to be given by two specifications:

• PKCS8KeySpec for private keys
• SPKIKeySpec for public keys

Both of those are usually sent around in a binary ASN.1 encoded form transformed in base64 as PEM documents. The binary encoding makes understanding what is wrong with them quite difficult as shown by bizarre problems such as in issue 1867 for the Signing HTTP Messages spec.

Luckily there are human readable JSON Web Key format that is supported by the Web Crypto API. This is widely used in new web based crypto protocols, and so should really be supported here too. One would then have to add something like the following

• JWKPublicKeySpec
• JWKPrivateKeySpec

It is helpful to keep this in mind as that should help in deciding about the public API for Signer and Verifier.

For Java this would I think require using an extra library such as "com.nimbusds" % "nimbus-jose-jwt" used in the demo test JWKCryptoSuite.scala.

If this dependency is problematic one should I guess make a separate project for it so that it can be pulled independently.

For reference typelevel/fs2#3070

Would be super helpful to be able to publish snapshots here so that I can test downstream in http4s CI. No urgency for this yet.

The branch on which PR #48 is located has asymmetric key support for browsers Web Crypto API, but not for Node.js. That would be a nice self contained project to add.

Should be easy with sbt-typelevel 🤞 .

The functionality is now available in CE 3.3.9.

• typelevel/cats-effect#2906