Ursa EOL

[berendsliedrecht]

Ursa has been moved to EOL status. This means that Anoncreds-rs has to move away from this library as it will not be updated or will get any security fixes.

There is some ongoing work for extracting the work, most notably for this library is anoncreds-clsignatures.

Looking at the codebase, with rg --pcre2 'ursa(?!::cl).*' . shows only some dependency Ursa::bn, which can be replaced with openssl (native depencency) / BigNum (pure rust). Everything else, which is in the cl package from Ursa should be moved to the anoncreds-clsignatures-rs repository, AFAIK.

If this is the only work, moving away form Ursa would be rather easy as long as anoncreds-clsignatures is finished.

@andrewwhitehead Do see any additional work or is really almost everything covered by anoncreds-clsignatures?

[TimoGlastra]

Would moving to openssl resolve some of the issues around anoncreds being slow in WASM?

[berendsliedrecht]

Would moving to openssl resolve some of the issues around anoncreds being slow in WASM?

No, that would need to be done in anoncreds-clsignatures as it is slow because of generating some 1024 bit safe primes for the credential definition.

The person behind libsodium has openssl working for WASM, https://github.com/jedisct1/openssl-wasm, but I am not sure about the build process of including this into rusts openssl-src/sys package so we can use it.

And possibly it is not even faster to use openssl-wasm instead of a pure rust as AFAIK the openssl version is quite faster because half of the big number implementation of openssl is done in assembly. Which would then be done with some polyfill / pure webassembly and I am not aware of any benchmarks between them.

[andrewwhitehead]

@andrewwhitehead Do see any additional work or is really almost everything covered by anoncreds-clsignatures?

I believe that should be the only (direct) dependency needed. If you're using the big number support directly then we may have to check that it's exposed.

The 'native' backend currently uses glass-pumpkin, but the prime generation is too slow to be practical (last I checked). A recent alternative might be crypto-primes but I haven't benchmarked that yet. There is also num-bigint-dig.