You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 11, 2024. It is now read-only.
Ursa will have many traits and structures that will be common across subprojects. The idea is that if at least two subprojects have a common item, this can live in the core subproject.
Here is a list of the currently known components that can live here
As part of this the Keys struct should be changed to be a placeholder trait such that each consuming subproject can expand it in their own way without having to extend an enum.
For example, all the keys are just generic wrappers around byte arrays like PrivateKey. While it works, Rust can provide stronger typing that wrapping a generic Vec.
We can similarly apply the same idea to the current enum KeyGenOption.
In the end, key generation should be flexible enough to be usable by any crypto primitive like signatures, short group signatures, post quantum methods, and others.
This also facilitates the FFI and WASM wrappers to just return the generic PrivateKey trait as part of their interfaces without having to worry about the specific implementations.
The text was updated successfully, but these errors were encountered:
Ursa will have many traits and structures that will be common across subprojects. The idea is that if at least two subprojects have a common item, this can live in the core subproject.
Here is a list of the currently known components that can live here
As part of this the Keys struct should be changed to be a placeholder trait such that each consuming subproject can expand it in their own way without having to extend an enum.
For example, all the keys are just generic wrappers around byte arrays like PrivateKey. While it works, Rust can provide stronger typing that wrapping a generic Vec.
If PrivateKey were changed to
The BLS, Ed25519, ECDSA could provide an implemented version that is the specific to them that is stronger typed
We can similarly apply the same idea to the current enum KeyGenOption.
In the end, key generation should be flexible enough to be usable by any crypto primitive like signatures, short group signatures, post quantum methods, and others.
This also facilitates the FFI and WASM wrappers to just return the generic
PrivateKey
trait as part of their interfaces without having to worry about the specific implementations.The text was updated successfully, but these errors were encountered: