Closed javisantos closed 4 years ago
@javisantos it’s important to use a performing, reputable, recognized crypto implementations.
Ideally, this missing cipher will be added to openssl and therefore also node’s crypto module. Since that’s not the case (yet), libsodium is the second best thing.
Furthermore, testing the bundle size of your fork it's actually higher and has more module dependencies. The crypto implementations of stablelib are pure javascript, as opposed to libsodium's native modules, ergo its slower as well, albeit sometimes within a margin of error.
❯ du -hs pasetowithstablelib
1.6M pasetowithstablelib
❯ du -hs paseto
1.1M paseto
libsodium V2.encrypt x 10,261 ops/sec ±3.53% (74 runs sampled)
stablelib V2.encrypt x 9,704 ops/sec ±3.11% (78 runs sampled)
libsodium V2.decrypt x 15,632 ops/sec ±2.76% (78 runs sampled)
stablelib V2.decrypt x 14,928 ops/sec ±3.04% (77 runs sampled)
I was just going to verify my expectation, but you did before :) I'll take into consideration, but then i'll have libsodium-wrappers and stablelib if i import paseto to my stack :thinking: . Thanks for the benchmarks
Hi @panva!
only to let you know that i forked this lib to replace libsodium-wrappers for @stablelib modules, the reason is because i didn't want to add more libraries (and weight) to my stack. I know is very subjective, so only if you want i can do a pull request. Just let me know.
Thanks for your amazing work!