rfc-leadership-council VS block-ciphers

This fork promises "All of the memory-safe features you love, now with 100% less bureaucracy!" Compelling, until you realise that all the commits are auto-merges of rust-lang/rust's main branch. Which means the same teams doing the same work, under a different name.

Rust is experiencing growing pains because they're still figuring out a governance structure that works for everyone. They want to simultaneously keep the current structure of bottom up development where each team (compiler, lang, crates.io, cargo) has the autonomy to make decisions for themselves, but the project as a whole can speak can come to a consensus and speak with a single voice. That's what this RFC tries to capture (https://github.com/rust-lang/rfc-leadership-council/blob/mai...). But the project isn't there yet, and is making these frustrating missteps in the interim. The lack of transparency into these missteps manifests as "bureaucracy" to outsiders like us.

If Crab lang actually attracted people doing the real work of development, they would have the exact same "bureaucracy" as teams tried to figure out how to build consensus and speak with one voice. The fact that they don't have bureaucracy is a direct consequence of them not doing any work right now. None of the people involved in regular Rust work, as far as I can tell, so they might not be aware of this.

Lastly, I want to note that the top comment in this thread is blaming the Foundation, which is simply bizarre. The Foundation very explicitly tries to stay hands off on technical decisions and does not interfere in how the teams organise themselves. You may disagree with that, but it's an inaccurate characterisation.

Read eg. https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md as start

If found this set of crates for other algorithms : https://github.com/RustCrypto/hashes And also found this set of crates that seem to include a lot of block cyphers : https://github.com/RustCrypto/block-ciphers Even if "des" is listed as a crate in this last link, it doesn't seem to provide the DES algorithm entirely.

If you are trying to use it as a library in your own crate then I would suggest looking at the [patch.crates-io] section of your Cargo.toml. It should allow you to override the dependency and point it to something else. Under that section set aes = { git = 'https://github.com/RustCrypto/block-ciphers', rev = 'e59142b26edcaa5e287c7e5067be8a501b42f9cb' }, changing the rev key to whichever commit has the right version of the crate when it was published. Then do the same for block-cipher and any others that it cannot find the version for but with the correct repository and commit.

aes (GitHub: RustCrypto / block-ciphers / aes) good: still maintained as of now - last commit on GitHub is from October 2021 good: examples look easy to use good: has received an audit by NCC Group bad: seems a bit too low level - the example provided only shows usage with data that is exactly block sized - seems there is no padding handling for real world use cases

I have no idea which libraries have the best code for Raspberry Pi 4. I think it doesn't have hardware AES, so an implementation of AES that doesn't leak secret bits through side channels and is fast would be complicated. The code I would trust is this: https://github.com/RustCrypto/block-ciphers but I have no idea whether it has python bindings. I would also sorry about correctly reusing buffers or else the memory allocation would be the bottleneck.

You should look at this this: https://github.com/rust-cc/awesome-cryptography-rust and you probably need this: https://github.com/RustCrypto/block-ciphers

For example, here is a bitsliced AES S-box written in single assignment form. Granted that's not the entire cipher, but the entire cipher can be implemented that way if you so desire.