Skip to content
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

librustzcash APIs for wallet key manipulation #9

Merged
merged 5 commits into from
May 31, 2018

Conversation

arcalinea
Copy link

@arcalinea arcalinea commented May 14, 2018

  • librustzcash_to_scalar
  • librustzcash_ask_to_ak
  • librustzcash_nsk_to_nk
  • librustzcash_crh_ivk
  • librustzcash_check_diversifier
  • librustzcash_ivk_to_pkd

@arcalinea arcalinea requested a review from str4d May 14, 2018 12:01
@ebfull
Copy link
Collaborator

ebfull commented May 14, 2018

Can you rebase this on top of the latest librustzcash?

@arcalinea
Copy link
Author

Rebased

@arcalinea arcalinea force-pushed the wallet-apis branch 4 times, most recently from 77b724f to b184cc6 Compare May 15, 2018 03:49
@str4d str4d changed the title WIP: Sapling to_scalar wallet API librustzcash APIs for wallet key manipulation May 15, 2018
@arcalinea arcalinea force-pushed the wallet-apis branch 2 times, most recently from 115f152 to 06990af Compare May 15, 2018 06:00
}

#[no_mangle]
pub extern "system" fn librustzcash_crh_ivk(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see why you might not want to use it though. It looks like you do the right thing here, so meh, it's okay.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, kinda. I think you should do what my code does, interpret it as a scalar (it should always work) and then use a write_fs afterwards, which should be implemented to write out in little endian bit order.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using that API requires six additional conversion read/write operations (to convert ak and nk to scalars and back, and to convert ivk to a Point and back). It didn't seem worth the cycles.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once this has been rebased, we should test this function against the test vectors.

src/rustzcash.rs Outdated

let result = unsafe { &mut *result };

scalar.as_mut().reverse();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should be doing some kind of write_fs here instead.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So extract it into a separate function like we did for read_fs?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried this in latest commit

/// Reads an FsRepr from [u8] of length 32
/// This will panic (abort) if length provided is
/// not correct
fn read_fs(from: &[u8]) -> FsRepr {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will read from bytes into an Fs in little-endian bit order, which is what we want, but the function librustzcash_crh_ivk produces a little-endian byte order result and writes that out. Then, when you call librustzcash_ivk_to_pkd, it's not going to work correctly.

Copy link
Contributor

@str4d str4d May 16, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it? I thought the intention was that the output of BLAKE2s was exactly the representation we wanted. More precisely, I think this is fine, because:

  • Here we are reading a little-endian byte array in big-endian, and then flipping, which means we need to flip both the u64s and their bits.
  • In ViewingKey.ivk() we flip the little-endian byte array before reading it as big endian, and since the endianness of the bits within each byte doesn't matter for reading, that should mean the result is the same as we get here by flipping the bits above.

I'll try and generate some test vectors to confirm.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that #12 has been merged, this function needs to be updated (to use read_le and not swap bits).

Copy link
Contributor

@str4d str4d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All new APIs should be tested against the test vectors that are now in master.

/// Reads an FsRepr from [u8] of length 32
/// This will panic (abort) if length provided is
/// not correct
fn read_fs(from: &[u8]) -> FsRepr {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that #12 has been merged, this function needs to be updated (to use read_le and not swap bits).

src/rustzcash.rs Outdated
*b = swap_bits_u64(*b);
}

f.write_be(to).expect("length is 32 bytes");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that #12 has been merged, this function needs to be updated (to use read_le and not swap bits).

}

#[no_mangle]
pub extern "system" fn librustzcash_crh_ivk(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Once this has been rebased, we should test this function against the test vectors.

@arcalinea arcalinea self-assigned this May 23, 2018
Copy link
Contributor

@str4d str4d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also needs tests (calling these functions inside the key component test function, and checking the output, should suffice).

src/rustzcash.rs Outdated
let mut f = <<Bls12 as JubjubEngine>::Fs as PrimeField>::Repr::default();
f.read_le(from).expect("length is 32 bytes");

f.as_mut().reverse();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needed to be removed as well.

src/rustzcash.rs Outdated
fn write_fs(mut f: FsRepr, to: &mut [u8]) {
assert_eq!(to.len(), 32);

f.as_mut().reverse();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needed to be removed as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the reverse() on line 80 also be removed?

@str4d
Copy link
Contributor

str4d commented May 30, 2018

I rebased this PR on master to fix merge conflicts and remove some stray commits that had crept in.

Copy link
Contributor

@str4d str4d left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK+cov

) {
// Should be okay, because caller is responsible for ensuring
// the pointer is a valid pointer to 32 bytes, and that is the
// size of the representation
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment is out-of-date (I think it might be intended to apply to the unsafe conversion of result).

@str4d str4d merged commit 18f4945 into zcash:master May 31, 2018
zkbot added a commit to zcash/zcash that referenced this pull request Jun 5, 2018
Add Sapling key classes to wallet

Leverages new librustzcash APIs added in zcash/librustzcash#9
str4d referenced this pull request in str4d/librustzcash Aug 28, 2018
Various improvements to project structure and implementation

This makes wNAF/multiexp more modularized and abstract (for use later in remodeling groth) and starts moving other things around.

Also, good chance to start working on buildbot.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants