Comments (9)
As a rule, the keypair is the secret key type and the actual private key type should never be used. It's okay to use the private key type for serialization though, as you can derive the keypair from the secret key.
from schnorrkel-js.
Based on the latest discussion with @jacogr who will be first to use this library I was informed that having the public/private portions separated is actually more convenient for him. This will still be open to change but I think it is fine as in the context of wasm exported function, none of the rust-defined data structures such as Private
and Public
exist anymore. Essentially, all of them will be seen as UInt8Array()
from the perspective of Javascript.
from schnorrkel-js.
It's fine to separate them for user facing js things that do not require high performance, just provide a sign function that calls .to_public()
or .expand_to_public()
. Anytime you want high performance then your code should use Keypair
as the secret key everywhere because the .to_public()
call is almost as slow as signing.
In practice, almost all methods in this library use only a Keypair
because doing so simplifies the code, so you'll need to call to_keypair().whatever()
. Ideally, I might've renamed Keypair
to SecretKey
and SecretKey
to PreSecretKey
or whatever, but sounds like that ship sailed.
from schnorrkel-js.
That rename would have helped ;) Never too late, we still need updates, so rather earlier than later.
But yes, the public portion is separated out since that is used (via ss58) to represent the address.
EDIT: With a rename (i.e. pair is actually secretKey), it makes more sense to pass it in as a whole
from schnorrkel-js.
I'm torn still because really all performant dlog crypto libraries should have keypair types that provide this optimization. It's maybe worse to hide the keypair form a person who is looking for it?
Also, there are two serializations for a keypair with maybe the best being to serialize only keypair.secret
and call .to_keypair()
when you get it back. Algorithms almost always require a pair but infrequent serialization wants just the secret.
If we renamed, then what name should the existing secret key be then? PureSecretKey
or TruePureSecretKey
maybe?
from schnorrkel-js.
Ok, now I get your dilemma... Not a cryptographer, so it took me a while to get on the same page. I can only comment on a external use perspective where (in "simpler" libraries, e.g. sodium), you only have the secretKey
to pass into the sign process. And publicKey
to verify those. So generally, those are the important external bits.
But then you start looking at derivation and friends, and well, clueless.
from schnorrkel-js.
In the end, this is a performance optimization, but it's often best to stick with the usual terminology.
I actually did one rename here already btw:
- SecretKey -> MiniSeretKey
- ExpandedSecretKey -> SecretKey
I felt justified in that rename because it's makes our soft BIP32 analog in derive.rs far more intuitive and no sane terminology or standards exists in that area.
Anyways just because I do one thing in schnorrkel does not mean that schnorrkel-js needs to do the same thing. If the js stuff is not used for anything high performance then you can call .to_public()
every time. It's not that slow. :)
from schnorrkel-js.
Based on the discussion I can propose the following to be A) more aligned with how the original schnorrkel is working B) performant C) easier to use for JS
- You get your secretKey via
// output vector will be 64 bytes; The real private key
pub fn secret_from_seed(seed: &[u8]) -> Vec<u8> {...}
I am not sure if we still need the keypair_from_seed
? @jacogr @burdges
- The get the public key to be used as address:
// output vector will be 32 bytes; The real public key
pub fn expand_to_public(secret: &[u8]) -> Vec<u8> {...}
- to sign something:
pub fn sign(secret: &[u8], message: &[u8]) -> Vec<u8> { ... }
- Verifying will stay the same.
pub fn verify(signature: &[u8], message: &[u8], pubkey: &[u8]) -> bool {
I think this is fulfilling in the sense that:
- From the JS's perspective, the
secret key
is the keypair - From my perspective, I will be mostly using Keypair und the hood.
I actually do agree that this looks better. Much better.
@jacogr I will implement this in a new branch. Once you're ready it will be merged.
from schnorrkel-js.
The above API is implemented but not yet merged published in #4.
from schnorrkel-js.
Related Issues (7)
- Improve error handling HOT 1
- Signing context may not be selected at runtime. HOT 11
- Build process HOT 2
- Packaging, again... HOT 4
- Circular dep in Wasm import HOT 6
- Expose key derivation HOT 6
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from schnorrkel-js.