block-ciphers VS rust-playground

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.

If you have an object that's !Unpin, then Miri will not apply uniqueness rules to anything containing it [0], including boxes and &mut references. (In the example code, replacing the PhantomPinned with a () will make Miri complain again.) This is considered a temporary (if long-lived) measure to allow async executors to manipulate pinned futures without invalidating all their references and whatnot. Thus, it might be seen as undetected UB, in lieu of a permanent solution.

[0] https://play.rust-lang.org/?version=stable&mode=debug&editio...

That would be true if you used `Vec::clear` too, it doesn't allocate a new vector. My point was that you still end up running Drop implementations with RepeatedField, just not all at once. See https://play.rust-lang.org/?version=stable&mode=debug&editio...

That's a valid Unix path, but rust's quoting does nothing to stop it: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Self-referential structs work fine in Rust and always have.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

The compiler will correctly prevent you from moving the value.

The other way to have a struct that starts out as non-self-referential and then becomes self-referential can be achieved with `unsafe` and `Pin::new_unchecked`, which is how `async {}` is handled.

In rust as currently stands: https://play.rust-lang.org/?version=stable&mode=debug&editio...

On the other hand, both this wrapper and yours are counterproductive if the element size is dynamic (e.g. perhaps you're dealing with some nonsense like:)

    struct ITableColumn {

Overflow checks turn into two's compliments' wrapping, but that's only considered acceptable because bounds checks are not turned off.

https://play.rust-lang.org/?version=stable&mode=release&edit...

I have no idea what you're talking about, but it sounds unnecessarily complicated and why I don't use Rust for any serious work.

This demonstrates the ABA problem in safe Rust: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Substitute the sleep with a combination of doing computation/work and the OS thread scheduler, and you can see how the bug surfaces.

You can also try Rust online using the Rust playground: https://play.rust-lang.org/

(Click ... beside build to get assembly) https://play.rust-lang.org/?version=stable&mode=release&edit...

Unfortunately the go playground doesn't seem to support emitting assembly?