Package is too big about avalanchejs HOT 16 CLOSED

I like it, esp for when aes-ni isn’t implemented — encrypting tls traffic on low-end mobile phones is a perfect use case for it.

from avalanchejs.

Soatok recently provided more reasons to ditch GCM: https://soatok.blog/2020/05/13/why-aes-gcm-sucks/

tl;dr in addition to what i've said above:

• using ghash to calculate MAC may create some collisions, so it can't be used in new PAKEs (not our case)
• short nonces: max blob size is 64gb (not our case), max amount of msgs w one nonce: around 2^48 (not our case)

In the end he mentions "Don’t throw AES-GCM out just because of my opinions. It’s very likely the best option you have." 😊

from avalanchejs.

I trust dchest's stuff. See: https://github.com/StableLib/stablelib/tree/master/packages/xchacha20poly1305. He makes great crypto.

Same problem as most others: too many dependencies, but at least it's all his. Perhaps the result would not be too big with it.

from avalanchejs.

@paulmillr

Soatok recently provided more reasons to ditch GCM: https://soatok.blog/2020/05/13/why-aes-gcm-sucks/

Ohai!

I trust dchest's stuff. See: https://github.com/StableLib/stablelib/tree/master/packages/xchacha20poly1305. He makes great crypto.

There's also:

• https://www.npmjs.com/package/xchacha20-js
• https://www.npmjs.com/package/poly1305-js

If you're looking for "minimal dependencies". They're used in sodium-plus, but as standalone packages.

from avalanchejs.

Ohhhhhh thanks! @soatok . Hey @cgcardona Can you look into this when you get a chance?

from avalanchejs.

Check out my noble-secp256k1. It's pure typescript/javascript library and it's faster than most other libraries. Wrote a blog post about it: https://paulmillr.com/posts/noble-secp256k1-fast-ecc/.

It works great with node and all major browsers except for Safari. Safari unfortunately doesn't have bigints, but is going to add 'em soon.

Using noble-secp instead of bn.js and current secp lib would allow you to reduce the bundle size by a huge chunk.

from avalanchejs.

Thank you, but this isn't the issue. We use the same elliptic library that Ethereum uses for secp256k1, which is reasonably decomposable and packages well. BigInt is also not yet a viable option, so we use BN.js for maximum browser coverage. The problem is the other stuff we want, like chacha poly1305 et al that's is found in the CryptoHelpers sub-library in slopes. The best solution I've seen at this point is to make that a completely separate library package.

from avalanchejs.

Is there any reason to use chacha instead of aes-gcm? gcm is widely supported and takes about 100 lines of code to implement in a cross-platform way. The reason being: it's built-in into node & browsers.

from avalanchejs.

There's a load of reasons to use ChaChaPoly1305 over AES:

https://crypto.stackexchange.com/questions/34455/whats-the-appeal-of-using-chacha20-instead-of-aes?fbclid=IwAR0Jjaj_vF4y-QWZc2Vjd_NPbloPHWVVYYy1NkCfvKsiecCrzaoZh7GoQX4

We don't let browsers dictate our security standards. The wallet will use ChaChaPoly1305. Gecko actually used to export this EXACT SAME format, but it was removed for a pure binary database dump, for reasons I'm still not clear on.

Anyway, back to your question: browsers really don't support BigInt either, but we have libraries which work around it. Same with ChaCha.

from avalanchejs.

Your call obviously, I don't care much here.

I wouldn't call "swiftness & lack of cache timing attacks but only when AES-NI ain't implemented" as "load of reasons". AES-gcm is perfectly fine. These issues automatically disappear once AES-NI compatible CPU is used. Timing attacks are very hard to execute. JS / Go are vulnerable to them in any case, since these are the languages with garbage collection. Js has jit. And it's not like you're encrypting terabytes of data.

New tech should not be rushed to. Doing so with djb's (chacha/poly creator) other piece aka ed25519 resulted in terrible vulnerabilities called "torsion point attack". Other projects got badly affected by this. A whole new arithmetics was invented to combat this, and now everyone is pushing towards ed25519 with the workaround. Meanwhile folks started heading back to prime order curves.

from avalanchejs.

I hear you. I suggest you should check out chacha a bit more, it's pretty robust and fairly widely used, despite browser adoption.

from avalanchejs.

I'm hearing what you're saying. Now that I've stepped away from my massive coding task and had a breather, I can get perspective. Maybe I'm too married to ChaCha, I'll have a think on it. Personally, I prefer it, but if availability is an issue, then maybe making it "official" isn't really the best thing. Especially with small amounts of data. Again, not sold entirely, but I'll have a think on it.

from avalanchejs.

I really do feel like a native JS implementation of ChaCha would work. I mean I know where to snag a really light weight one, but I don't just trust any random crypto implementation I find on the internet, ya feel?

Like if you view source on this page, there's a very small lightweight version: https://asecuritysite.com/encryption/poly1305

...and if you check NPM you'll find some as well.

If I'm going to be this picky, though, I should maybe consider wrappers around WebCrypto using AES instead.

I'm really feeling like CryptoHelpers should not be directly included in slopes, though, and should be its own standalone helper library if anything.

from avalanchejs.

Confirmed. I'll look in to it.

from avalanchejs.

Latest push on the development branch ditched libsodium and switched chacha20poly1305 to AES-GCM. This reduced us from 1.2mb to ~850kb.

Still more work can be done to reduce file size, but that's a nice start.

from avalanchejs.

The package is where it is for the time being. Optimization can be handled through partial import facilities in nodejs.

from avalanchejs.