spake2: `no_std` support

[fmckeogh]

I'd like to start working on optional no_std support, is there anything major preventing this, and if not, is it the sort of thing you would like to see merged?

[newpavlov]

Both srp and spake2 depend on num-bigint which currently does not support no_std.

With stable alloc we could support no_std out-of-box, or alternatively I think with (stable) const generics we could migrate srp to fixed-sized stack-allocated big-integers (or num-bigint could add support for them), not sure about spake2 though.

cc @warner

[fmckeogh]

Ah okay, thank you! :)

[warner]

I just noticed that spake2 was only using num-bigint for the unit tests, so I demoted it to a dev-dependency. Maybe that'll help.

[fmckeogh]

Awesome :)

I'm still working on a heapless_bigint crate; I hope to make some more progress with making SRP no-std in the next few weeks, but I've just been pretty busy lately :/

[warner]

incidentally, PR #33 would increase at least the spake2 MSRV to rust-1.36, in which alloc is stable, which might help.

I know the curve25519-dalek crate that spake2 uses is a big fan of no_std, so I don't expect any problems from that dependency.

[Frostie314159]

Hi, is spake2's dependency on alloc a hard requirement, or simply due to how it is implemented? I'm not that familiar with the algorithm, but from scrolling through the code, it seems doable to remove alloc altogether.

[tarcieri]

@Frostie314159 it's just how it's implemented. "Heapless" no_std support would require adding a parallel API which gets rid of usage of Vec (and ideally still implements the Vec-based API in terms of the heapless API)