acolytec3

Added another commit to replace the noble re-export of node's `crypto` module with with the direct `crypto` import from nodejs. Hopefully, this will allow me to properly polyfill it in...

> `base64url` could also be replaced with audited version of one inside https://github.com/paulmillr/scure-base. We could put that in a second PR as well. I'm guessing that's non-breaking and this one...

> Thank you for the contribution! Overall looks good > > But please you or @wemeetagain must add benchmarks to show performance of hotpath ops vs this PR and current...

Okay, the cipher piece is fixed. Will look at some benchmarks later today. @dapplion are you thinking mainly encode/decode packets and then sign/verify since that's where the changes in this...

I added a benchmark script that uses `dapplion/benchmark` and I must say, the results are somewhat discouraging with regard to `sign`/`verify`. I can't say I'm surprised since `@noble/secp256k1` is pure...

> The pure results on M1 are as such: > > ``` > generatePrivateKey() x 265,957 ops/sec @ 3μs/op > getPublicKey(generatePrivateKey()) x 6,300 ops/sec @ 158μs/op > sign x 4,888...

> Haven't had a chance to dig into the benchmarks, but one thing we may be able to do re: the slowdown is make the crypto "pluggable", like we did...

> > have to think through the best approach given that it's really 4 different underlying dependencies > > Good point! I'm hoping to avoid spreading this to the ENR...

> For aes, we're using this approach in EF repo: https://github.com/ethereum/js-ethereum-cryptography/blob/master/src/aes.ts > > It uses node or web browser native built-ins. I'm sure there is zero need in polyfilling AES...

> > I guess some decisions could be made about which functions are synchronous vs asynchronous > > @wemeetagain please don't make the API async :pray: we are already doing...