-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ZIP 32 APIs #29
ZIP 32 APIs #29
Conversation
63 chunks per pedersen hash segment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK; however, this PR has no tests.
source = "registry+https://github.com/rust-lang/crates.io-index" | ||
dependencies = [ | ||
"aes-soft 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)", | ||
"aesni 0.4.0 (registry+https://github.com/rust-lang/crates.io-index)", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't reviewed these; I'm just assuming they correctly implement AES.
@@ -270,6 +270,35 @@ extern "C" { | |||
uint64_t vpub_old, | |||
uint64_t vpub_new | |||
); | |||
|
|||
/// Derive the master ExtendedSpendingKey from a seed. | |||
void librustzcash_zip32_xsk_master( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use extsk
, extfvk
, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh? I thought we decided on xsk
and xfvk
for the ZIP 32 constructs (as used in ZIP 32 itself), and expsk
/ fvk
for the corresponding Sapling key structs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ZIP 32 uses Ext*
.
src/rustzcash.rs
Outdated
pub extern "system" fn librustzcash_zip32_xsk_master( | ||
seed: *const c_uchar, | ||
seedlen: size_t, | ||
xsk_m: *mut [c_uchar; 169], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/_m/_master/
src/rustzcash.rs
Outdated
|
||
#[no_mangle] | ||
pub extern "system" fn librustzcash_zip32_xsk_derive( | ||
xsk_p: *const [c_uchar; 169], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/_p/_parent/
src/rustzcash.rs
Outdated
|
||
let xfvk = match xfvk_p.derive_child(i) { | ||
Ok(xfvk) => xfvk, | ||
Err(_) => return false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't (say) zero the output array in case of error. libsodium does that and I think it's a good idea. Does not block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to do that, we should do so consistently in all of the FFI APIs. Opened #34.
Rebased on master to fix merge conflicts, and address @daira's comments. |
.expect("valid ExtendedFullViewingKey"); | ||
let i = zip32::ChildIndex::from_index(i); | ||
|
||
let xfvk = match xfvk_parent.derive_child(i) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add somewhere descriptive error message for hardened child index?
The one in derive_child
just returns an error without a message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That should happen in the librustzcash repo now, where we should have a better overall error story instead of arbitrary strings. As for here, we don't get to easily send error states across the FFI :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where should that happen exactly? Isn't this librustzcash?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I meant in the refactor work happening in the master branch. This PR is merging into a 2.0.1-specific branch, which will later be merged into master.
unsigned char *xfvk_i | ||
); | ||
|
||
/// Derive a PaymentAddress from an ExtendedFullViewingKey. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering how this will be designed to work without repeating addresses. E.g. if j_ret=j+1
we should store j_ret
somewhere to know we should start from j+2
for the next address.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct; you are given back the "index" of the address being returned, and should store it so that you know to try index + 1
the next time you want an address.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if the following interface is better: You give as input the index j of a valid diversifier - the method return an error if j is not a valid index; and if it is, returns the next valid diversifier
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be; we can explore that in a follow-up PR when we have more users of the API.
Use ZIP 32 for all Sapling spending keys The wallet now only stores Sapling extended spending keys, and thus can only be used with keys generated from an HDSeed via ZIP 32. This means that all Sapling keys and addresses generated by users can be recovered as long as they have a backup that includes the seed. Depends on zcash/librustzcash#29 Closes #3380.
Use ZIP 32 for all Sapling spending keys The wallet now only stores Sapling extended spending keys, and thus can only be used with keys generated from an HDSeed via ZIP 32. This means that all Sapling keys and addresses generated by users can be recovered as long as they have a backup that includes the seed. Depends on zcash/librustzcash#29 Closes #3380.
Use ZIP 32 for all Sapling spending keys The wallet now only stores Sapling extended spending keys, and thus can only be used with keys generated from an HDSeed via ZIP 32. This means that all Sapling keys and addresses generated by users can be recovered as long as they have a backup that includes the seed. Depends on zcash/librustzcash#29 Closes #3380.
No description provided.