Signed-off-by: Axel Nennker [email protected]

I think that, in general, Cargo.lock should not be in version control of libraries like ursa.

libindy uses ursa but ursa is using an older version of openssl-sys than libindy

(Kind of hoping that using the same, newer versions help with libindy's CI-run failures on Ubuntu 18.04)

@tarcieri mentions in #162 an alternative to libsecp256k1. I think the selection of the libsecp256k1 was for minimalist builds for e.g. mobile devices. Performance differential should be evaluated as well. Please discuss other criteria to evaluate. Current: https://crates.io/crates/libsecp256k1 Proposed: https://crates.io/crates/k256

This method is compatible with libsodium's crypto_sign_ed25519_sk_to_curve25519.

This PR also adds Ed25519Sha519::keypair_from_secret which is compatible with libsodium's crypto_sign_seed_keypair. @mikelodder7 I didn't add this as a separate KeyGenOption as it didn't seem to be generally applicable, but I'll let you be the judge.

Description of changes

Upgrade from 1.0.0-pre.2 to 1.0.0-pre.3 And corresponding fixes for other lib versions and src files

Benefits

There is an issue with the usage of latest ursa (0.3.2) with latest libp2p(0.16.2): they have incompatible versions of ed25519-dalek (ursa - 1.0.0-pre.2 and libp2p - 1.0.0-pre.3). It could be solved only by downgrading libp2p to version 0.13.1 which is rather old now.

Therefore this PR is meant to fix that and make latest ursa and libp2p compatible, as they have rather intersecting user groups in my opinion.

Signed-off-by: Egor Ivkov [email protected]

This PR adds libursa-specific jobs to GH Actions (namely building libursa and running its tests).

One thing I'm not sure about is the workaround for getting libursa to build on its own -- currently, running cargo build in the libursa directory on the main branch will yield this error:

error: current package believes it's in a workspace when it's not:
current:   ursa/libursa/Cargo.toml
workspace: ursa/Cargo.toml

this may be fixable by adding `libursa` to the `workspace.members` array of the manifest located at: ursa/Cargo.toml
Alternatively, to keep it out of the workspace, add the package to the `workspace.exclude` array, or add an empty `[workspace]` table to the package's manifest.

I heeded the second suggestion and excluded libzmix and libursa from the workspace, but I'm not sure if this is the correct course of action. Feel free to request/make changes!

As for the changes to libursa/src/kex/secp256k1.rs, the compatibility test was never updated after libsecp256k1 was replaced with k256 in #171, so this PR also fixes that.

This PR updates to a newer version of amcl_wrapper as well as implements a compressed form for keys and proofs.

For example, points can be stored as just the x-coordinates. Curve order elements can remove leading zero bytes.

The result is that points in G1 drop to 48 bytes, G2 drop to 96 bytes, and elements in Zq drop to 32 bytes.

The major gains come from proof sizes. A proof with 5 hidden messages is 933 bytes in uncompressed form and 530 in compressed form.

Public Key sizes go down to 1/2.

Signatures go from 193 bytes to 112 bytes.

We have a dependency collision with cosmos_sdk=0.1.1 crate in our project.

error: failed to select a version for `ed25519-dalek`.
    ... required by package `tendermint v0.19.0`
    ... which is depended on by `cosmos_sdk v0.1.1`
    ... which is depended on by `libindy v1.95.0 (.../libindy)`
versions that meet the requirements `^1` are: 1.0.1, 1.0.0

all possible versions conflict with previously selected packages.

  previously selected package `ed25519-dalek v1.0.0-pre.3`
    ... which is depended on by `ursa v0.3.5`
    ... which is depended on by `libindy v1.95.0 (.../libindy)`

failed to select a version for `ed25519-dalek` which could resolve this conflict

The version of ed25519-dalek is already updated in master. Could you please publish it to crates.io?

To allow speeding up credential definition creation we wanted to create the safe prime numbers beforehand with ursa::helpers::generate_safe_prime and hold onto them until the actual credential definition is created.

In our use case we have to create multiple credential definitions at a time and having a bunch of safe primes ready for this improves performance of this a lot. :)

Compilation currently fails when the cl feature is enabled due to the digest dependency being updated previously.

Also fixed some warnings and skipped tests around the optional serde feature and non-existent serialization feature.

• Runs a CI pipeline for incoming PRs and merges to main.
  • audit
  • build
  • check
  • clippy
  • docs
  • format
  • tests
• Removed some files that I assumed are not used (please give this a careful review as I am not fully aware of the history of these files).
• Does not include the release to crates.io just yet.
• Moved the ursa_ packages to an Ursa folder to keep the root a bit cleaner. They kept the ursa_ prefix as we might want to release them as seperate packages, although some of them are empty.

According to the example of use of CL, i cross complie it with openwrt(arm) successfully, but when i make it on my router, i met the segment fault. I can't find the reason and don't konw how to fix it.

Ursa crashes if seed length is less than 32 bytes for secp256k1, but other algorithms work fine with this seed.

The problem seems to be that in other cases the input seed is hashed before being passed to the rng generator.

Minimal example that reproduce issue

use ursa::{
    keys::KeyGenOption,
    signatures::{
        secp256k1::EcdsaSecp256k1Sha256,
        SignatureScheme,
    },
};

fn main() {
    let options = KeyGenOption::UseSeed(vec![1, 2, 3]);
    let key_pair = EcdsaSecp256k1Sha256::new().keypair(Some(options));
    println!("{:?}", key_pair);
}

According to ed25519-unsafe-libs the library that is used for signing, ed25519-dalek, possibly contains a security bug that allows for private key extraction (as explained in this stack overflow post.

Now, the README mentions that it is not likely that libraries, like Ursa, using the "unsafe" library will also be "unsafe", but I thought I should mention it here.

I am by no means an expert in this, so likely it is just nothing, but it never hurts to mention it.