Add #![no_std] (fixes #16)

[tarcieri]

This crate does not depend on std. I would like to use it in a #![no_std] Rust program, but to do that this library can't link against std.

[tarcieri]

Might want to wait for another release of arrayref before merging this /cc @droundy

[isislovecruft]

Approved, but I'm leaning towards waiting for a new version of arrayref.

Also, is there some reason why using core instead of std would be slightly slower? The bench tests seem to be telling me it's a bit slower.

[isislovecruft]

@tarcieri I was vaguely considering using https://github.com/stouset/secrets, which wouldn't be compatible. I'm not sure whether to prioritise protecting/guarding memory allocated to hold secrets or to prioritise platform independence. It seems like the optimal solution would be for higher-level crypto protocols like https://github.com/isislovecruft/ed25519-dalek to use https://github.com/stouset/secrets and for curve25519-dalek to prioritise usability anywhere. (Thoughts, @hdevalence?)

[tarcieri]

@isislovecruft you can gate features that use std via cargo features, which can even be enabled by default and selectively disabled for the #![no_std] use case. For example you could make a cargo feature called std that all of the ::std-dependent features are gated on.

Re: memory protection, you might find this thread informative: rust-lang/rfcs#766 (comment)

[burdges]

It might suffice to avoid returning secret data by value, which allow LLVM to move it around the stack willy nilly. In fact, I was just about to raise an issue mentioning that four fns random, pack_limbs, multiply_add, and reduce return a Scalar by value.

There are actually tricks where by a return by value avoids the stack, at least in release builds, like say immediately calling box on it. Anything like that sounds hard to maintain though, so providing a buffer is safer and punts the stack safety issue onto the caller.

I suspect any stack buffers allocated internally by your own code should be less risky, but one can imagine many games to address that too.

[burdges]

Also we should expect changes in the secure memory crate space as allocators slowly stabilize.

[tarcieri]

It appears rand still links against std, so to make this crate truly #![no_std] we'll need to feature-gate the functionality that uses rand on std. I can update this PR with that.

[tarcieri]

Ok, I've updated my PR to add an "std" cargo feature which is enabled-per-default which the rand crate is now gated on.

I have confirmed my #![no_std] project now builds and links against curve25519-dalek when default-features = false is used in Cargo.toml.

So long as any additional std-dependent crates you may use are gated on #[cfg(feature = "std")], this change should be invisible to std users while allowing the crate to build/link in #![no_std] environments.

[tarcieri]

I went ahead and put this back for now, however the released crate still depends on std. I can build my project by pulling in arrayref via git, but FYI it'd be nice to bump this whenever there's another release.

[tarcieri]

I think this is ready to merge

[tarcieri]

Ok, I spoke too soon: this needs the new arrayref crate to be released before it can be merged

[droundy]

I've just published arrayref 0.3.3, which should enable you to move forward.

[tarcieri]

@droundy awesome thanks! I think @isislovecruft was noting a 5% performance reduction from this PR... any idea if arrayref could be responsible? (nothing else seems like a likely culprit)

[tarcieri]

I think this is actually ready to merge now

[droundy]

I would be surprised if arrayref could be responsible. Did you change the code to use arrayref, or change the arrayref version? I could imagine that using arrayref could impact placement of arrays on the stack maybe? David

…

On Wed, Jan 18, 2017 at 5:12 PM Tony Arcieri ***@***.***> wrote: I think this is *actually* ready to merge now — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/isislovecruft/curve25519-dalek/pull/17#issuecomment-273652894>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAIZKQcVukUA5f4WIlV7WZxDm-geEQveks5rTrhogaJpZM4Lje57> .

[isislovecruft]

@droundy Thanks for the new arrayref release! We've been using 0.3.2 this whole time.

[isislovecruft]

@tarcieri I've merged and released curve25519-dalek-0.3.0. Thanks for all your help! Let me know if there's anything else we can do to make this usable for your projects.