Document the lack of side channel resistance about nisty

[nickray]

If the CPU you're running on doesn't provide constant-time multiply, you're pretty much screwed.

Right, nisty/salty both emphatically assume Cortex-M4 or M33, giving this and the UMAAL speedup.
The interesting reference here is http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100166_0001_00_en/ric1417175924567.html

[nickray]

I left out micro-ecc's RNG parts on purpose, not due to difficulty (in the beginning, I experimented with a ChaCha20 RNG using https://github.com/RustCrypto/stream-ciphers/tree/master/chacha20).

In my current thinking, the following are practical threats, in descending order of importance: trivial entropy failures, basic timing side channels (branching on secret data), differential side channels (what I assume you're alluding to, since the secret is being hashed perhaps?), fault injections (too vast for me to even start to reason about).

While micro-ecc claims to be resistant to timing attacks, I've not in any way audited that. Low priority, I'd like to reimplement the crypto backend in Rust, and/or add testing a la sidefuzz against timing leaks - if so, I'd do this for salty first, though. So in the above ordering, I'm not concerned about deterministic signature failure modes such as https://dl.acm.org/doi/10.1145/2858930.2858932.

In any case, I was delighted to see micro-ecc expose deterministic signatures, which is what I expose here. This is really meant to be "salty for when it must be P-256", e.g. in your case. BTW could rubble use 25519 or does the standard only allow P-256?

Agree to add a section on design decisions, although I'm not planning to write a treatise on cryptography :)

[jonas-schievink]

That sounds very reasonable to me. I'm not really worried about side-channel resistance for my use case, it just seems like a thing that should be documented.

BTW could rubble use 25519 or does the standard only allow P-256?

Unfortunately the standard requires P-256 (and P-192 for other insecure setups I don't currently care about), otherwise I would indeed be using a better curve.

[nickray]

The thing with side-channels is that the compiler can always randomly insert a branch on anything if you're not writing assembly... 😁

[tarcieri]

I left out micro-ecc's RNG parts on purpose, not due to difficulty (in the beginning, I experimented with a ChaCha20 RNG using https://github.com/RustCrypto/stream-ciphers/tree/master/chacha20).

Any particular problems you had with this crate?

If ChaCha20 proved too slow, note that per the Too Much Crypto paper I'd like to expose ChaCha8 and ChaCha12, possibly gated under a cargo feature.

[tarcieri]

I'm not really worried about side-channel resistance for my use case, it just seems like a thing that should be documented.

It's a difficult thing to document, as ultimately it's a property of a combined hardware/software system, so at best you can only document it architecture-by-architecture/device-by-device.

If the CPU you're running on doesn't provide constant-time multiply, you're pretty much screwed.

The thing with side-channels is that the compiler can always randomly insert a branch on anything if you're not writing assembly... 😁

👆Also this

[nickray]

Any particular problems you had with this crate?

Not at all, no! The hashes and symmetric ciphers from RustCrypto are perfect for my use cases, and I intend to use them all as needed since they work so well in no_std settings. I plan to extend salty to full NaCl by adding key agreement with Haase's field implementation, and then using RustCrypto for the AEAD, just need to balance my time right now.

I removed the RNG part again just because I wanted nisty and salty to have "parallel" APIs: have the user take responsibility for generating 32 bytes of entropy to generate keys, and then do everything deterministically. I may or may not revisit this in the future, and add ChaCha20Rng to both in some form.

If ChaCha20 proved too slow, note that per the Too Much Crypto paper I'd like to expose ChaCha8 and ChaCha12, possibly gated under a cargo feature.

Yeah that's a nice paper, and particularly for embedded having faster yet safe implementations would be great. No current urgency from my side though.

[nickray]

Closing this for now, if you have a concrete non-alarmist suggestion on what to add, please send a PR.