Too monolithic

[SoniEx2]

rust-crypto should consider deferring implementation to other, smaller crates.

Give me standalone AES crate, have rust-crypto just glue everything together.

rust-crypto should have 100 dependencies, one for each crypto subsystem.

[newpavlov]

Take a look at RustCrypto organization, it does exactly what you've described. It's still work in progress, so some algorithms are missing.

[SoniEx2]

Still too monolithic. Crypto crates should also be independent.

[newpavlov]

Wat? Crates are completely independent from each other (well, if we exclude dependency on common trait crates to abstract functionality and small utility crates) and published as standalone crates (sha2, sha3, aesni, pbkdf2 and many others). What did you expect to find? Separate repository for each crate? It will be nightmare to maintain and promote to say at least.

[SoniEx2]

Yes, separate repository, and less shared dependencies.

If you want to maintain it alone, sure, it would be extremely difficult. The right way is to get someone else to maintain some crypto, and split it off the organization or w/e.

[SoniEx2]

It would be best if we had more different ppl working on bite-sized bits of crypto. Bite-sized codebases are easier for interested parties to analyze, it would also encourage users of TLS to analyze all the crypto suites supported by it, as they'd have to be manually enabled (as opposed to manually disabled). This would encourage ppl to only enable the most common ones, hopefully forcing less-secure ones into disuse.

[19h]

Too monolithic means “bloats your binary size” for me. I'm using scrypt, sha256 and AES CBC in a WebAssembly module and the total resulting binary is less than 48KB. That's not exactly monolithic for me.

If you're talking about code centralisation, then I disagree even more. Isolating functionality and keeping interdependencies low is already an achievement.

But maintaining functionality separate from each other is just an invitation for questionable design decisions in a single functionality that lead to conceptual disparity and probably even interface inconsistence between individual “subfeatures.”

I'd close this issue.

[SoniEx2]

Python gets it right. There's a hash module and it just calls to external stuff. Granted by default the only external stuff it calls to is openssl, but I'd argue that's an implementation detail.

All that matters is that you have some well-specified traits. and everything uses that common API.

[19h]

All that matters is that you have some well-specified traits. and everything uses that common API.

I definitely agree with that point. You'd have some pretty weird interdependencies though if those traits happened to be in a different repository, I'd imagine.