Arithmetic feature requires atomics

[alistair23]

Currently using the arithmetic feature requires atomics. Compilling on a platform without atomics (such as RV32IMC) results in this error:

error[E0432]: unresolved imports `core::sync::atomic::AtomicBool`, `core::sync::atomic::AtomicI16`, `core::sync::atomic::AtomicI32`, `core::sync::atomic::AtomicI8`, `core::sync::atomic::AtomicIsize`, `core::sync::atomic::AtomicPtr`, `core::sync::atomic::AtomicU16`, `core::sync::atomic::AtomicU32`, `core::sync::atomic::AtomicU8`, `core::sync::atomic::AtomicUsize`
  --> /home/alistair/.cargo/registry/src/github.com-1ecc6299db9ec823/radium-0.3.0/src/lib.rs:29:11
   |
29 |     self, AtomicBool, AtomicI16, AtomicI32, AtomicI8, AtomicIsize, AtomicPtr, AtomicU16, AtomicU32,
   |           ^^^^^^^^^^  ^^^^^^^^^  ^^^^^^^^^  ^^^^^^^^  ^^^^^^^^^^^  ^^^^^^^^^  ^^^^^^^^^  ^^^^^^^^^ no `AtomicU32` in `sync::atomic`
   |           |           |          |          |         |            |          |
   |           |           |          |          |         |            |          no `AtomicU16` in `sync::atomic`
   |           |           |          |          |         |            no `AtomicPtr` in `sync::atomic`
   |           |           |          |          |         no `AtomicIsize` in `sync::atomic`
   |           |           |          |          no `AtomicI8` in `sync::atomic`
   |           |           |          no `AtomicI32` in `sync::atomic`
   |           |           no `AtomicI16` in `sync::atomic`
   |           no `AtomicBool` in `sync::atomic`
30 |     AtomicU8, AtomicUsize, Ordering,
   |     ^^^^^^^^  ^^^^^^^^^^^ no `AtomicUsize` in `sync::atomic`
   |     |
   |     no `AtomicU8` in `sync::atomic`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `radium`.

To learn more, run the command again with --verbose.
make: *** [Makefile:141: flash-opentitan] Error 101

cargo tree reports that Radium comes from:

├── ecdsa v0.8.0
│   ├── elliptic-curve v0.6.0
│   │   ├── bitvec v0.18.3
│   │   │   ├── funty v1.0.1
│   │   │   ├── radium v0.3.0
│   │   │   └── wyz v0.2.0

I have opened an issue for Radium: ferrilab/radium#3 but it would also be great if these libraries could stop depending on it.

[alistair23]

The current v0.4.1 release doesn't have the dependency, so it must be a change between v0.5.0 ad v0.6.0 of elliptic-curve.

This is probably the commit that causes the requirement on atomics: RustCrypto/traits@59e67e0

It would be great if signing and other operations could be supported without atomics via a feature flag.

[tarcieri]

Yes, we're now pulling in bitvec by way of the ff crate.

This is actually a superfluous dependency (at least at present). I opened this issue about making bitvec an optional dependency of ff:

zkcrypto/ff#42

[alistair23]

That would be great!

[alistair23]

Otherwise I don't think signing is possible, I just keep getting this error when trying to call try_sign_recoverable_prehashed():

error[E0599]: no method named `try_sign_recoverable_prehashed` found for struct `ecdsa::signer::Signer<p256::NistP256>` in the current scope
   --> examples-features/ctap.rs:410:30
    |
410 |             let sig = signer.try_sign_recoverable_prehashed(data, None).unwrap();
    |                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ method not found in `ecdsa::signer::Signer<p256::NistP256>`

error: aborting due to 2 previous errors; 6 warnings emitted

[tarcieri]

@alistair23 that method doesn't exist in the p256 crate (it's a private, inherent method in the k256 crate alone).

Here's a usage example:

https://docs.rs/p256/0.5.0-rc/p256/ecdsa/index.html#signingverification-example

[alistair23]

Thanks @tarcieri, unfortunately the new sign() function depends on arithmetic which requires atomics.

[tarcieri]

Yeah, you need the ecdsa feature enabled in order to create signatures, which depends on arithmetic.

There's not that much that can be done about that immediately. I'd say stay on p256 0.4 until either ferrilab/radium#4 is merged and bitvec updated, and/or zkcrypto/ff#42 is merged and we can disable the bitvec dependency.

[alistair23]

Hopefully one (or both) of those will be merged soon. Until then it looks like only sign_with_rng() is available, which doesn't appear to work without std.

[tarcieri]

@alistair23 sign_with_rng doesn't need std. If you're seeing std linkage, it's probably because some other dependency of yours is activating the std feature of rand_core.

However, sign_with_rng also needs the ecdsa feature (and with it arithmetic) and is documented as such:

https://docs.rs/p256/0.5.0-rc/p256/ecdsa/type.SigningKey.html

This is supported on crate features ecdsa-core and ecdsa only.

[alistair23]

Just an update, this seems to be fixed with a PR for Radium: ferrilab/radium#4

[alistair23]

This has been fixed: ferrilab/radium#3

Do you mind updating the crate dependencies?

[tarcieri]

Unfortunately it’s a deep transitive dependency. Looks like bitvec needs to update to radium v0.5 then ff needs to update to a new release of bitvec. After that group needs to upgrade ff, and then elliptic-curve can update ff and group.

[str4d]

The fix has been backported as bitvec 0.18.4, so you should now be able to cargo update to address this.