no_std

[aep]

we're migrating away from rust, but one of the things that's holding me back is snow, since it's fairly high quality and noise-c is .. not.

how do you feel about supporting no_std? That is, i'll do the majority of the work of course, but you'd have to maintain and defend it later :D

[mcginty]

I am very in favor of supporting no_std, targeting the 0.7 release. I started researching a bit removing our extensive use of Box. So far it's been promising, and would love feedback and collaboration on the architecture for this change.

[aep]

nice!
intermediately, you can just use the alloc crate, which offers Box.

but reducing heap in general is very welcome

[aep]

this is more difficult than expected because cargo will pull in rand with dependencies anyway because its specified somewhere down the default resolver dependencies

carving out the default implementation into a separate crate would solve this. would you be ok with it?

[tarcieri]

@aep are you running into one of these issues, perhaps?

rust-lang/cargo#4664
rust-lang/cargo#4866

[aep]

yes! its criterion.
that's actually easier to fix then.

with this diff it works
aep@78426ea

all of these are upstreamable, except removing criterion, but this isn't even strictly necessary.
would be nice to have CI complain when someone breaks no-std tho

[tarcieri]

@aep aah yep, I've run into that a lot with criterion specifically.

One option is to make a benches (or thereabouts) crate and make it part of the same workspace. This should (hopefully) work around the spurious feature activation, and cargo bench --all will still work

[mcginty]

That change (making separate benches crate in the same workspace) sounds fine to me if it allows us to be no_std compatible :).

[nickray]

@aep are you still planning to do any work on this? I am interested in Snow for a variant of PIV I'm implementing on Cortex-M33 microcontrollers, where I'd like to use Noise to establish Secure Messaging. Ideally, I would like to avoid alloc, so I'm wondering whether it makes more sense to modify Snow to be alloc-free, or rather to reimplement a subset in a separate library.

@mcginty how's your research going? One way I'd hope that Box<dyn Hash> and friends could be replaced is with generics, but it's a bit hard to get rustc to work this way. Specifically, I tried having multiple backends in a microcontroller Ed25519 library I'm working on, but ultimately gave up and used feature flags, meaning algorithm choices need to be made at compile time. Another approach would be doing what enum_dispatch does.

[tarcieri]

@nickray I'm interested in doing something quite similar! (not PIV or that class of token, but trying to encrypt a channel to a USB device)

One way I'd hope that Box and friends could be replaced is with generics

I'd suggest using traits from the RustCrypto project:

• https://crates.io/crates/aead
• https://crates.io/crates/digest

They're object safe and widely supported. There's an open PR for ring-digest, and I'd like to make a similar wrapper for using ring with the Aead trait. It'd also let you use e.g. the chacha20poly1305 and aes-gcm crates, which are pure Rust and should be both small and embedded-friendly.

I see how the current type erasure-based API is convenient. I'm curious if it might make sense to split the API between a monomorphizing version with generic parameters and one that uses Box/type erasure.

Perhaps, with default generic parameters, it'd be possible to make the Box-based API a default generic type? e.g.

struct Encryptor<C: Cipher = Box<dyn Cipher>> { ... }

I've never tried that before but it seems like it could work?

Otherwise it seems like you could split the generic vs type erasing structs into two different ones, and have one wrap the other.

[aep]

@nickray unfortunately no. after 5 years of trying to do rust on embedded we have decided that it's not the right tool. Reimplementing noise in zz (https://github.com/aep/zz) was a more effective path than maintaining the hacks necessary to get the last remaining rust code (this crate) working.

[tarcieri]

Note: I made a ring-aead crate for using the aead::Aead trait with ring's cipher implementations:

https://github.com/RustCrypto/AEADs/tree/master/ring

[benma]

unfortunately no. after 5 years of trying to do rust on embedded we have decided that it's not the right tool

@nickray could you please elaborate a bit on why it wasn't the right tool for you?

[nickray]

That's @aep :)