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

Update CCryptoKeyStore with Sapling support #3396

Merged
merged 14 commits into from Aug 3, 2018

Conversation

arcalinea
Copy link
Contributor

@arcalinea arcalinea commented Jul 12, 2018

Sapling crypter overrides for various CCryptoKeyStore functions such as:

  • HaveSaplingSpendingKey()
  • GetSaplingSpendingKey()

Also includes some changes to prepare for diversified addresses and ZIP 32.

Closes #3389

@arcalinea arcalinea added the NU1-sapling Network upgrade: Sapling-specific tasks label Jul 12, 2018
@arcalinea arcalinea added this to the v2.0.0 milestone Jul 12, 2018
@arcalinea arcalinea self-assigned this Jul 12, 2018
@arcalinea arcalinea added this to Review Backlog in Arborist Team Jul 12, 2018
@arcalinea arcalinea changed the title Add Sapling have/get sk crypter overrides Add Sapling have/get spendingkey crypter overrides Jul 12, 2018
@str4d str4d moved this from Review Backlog to In Review in Arborist Team Jul 13, 2018
@str4d str4d added the A-wallet Area: Wallet label Jul 13, 2018
str4d
str4d previously requested changes Jul 13, 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 add Sapling support to CCryptoKeyStore::EncryptKeys

uint256 SaplingFullViewingKey::GetHash() const {
CDataStream ss(SER_NETWORK, PROTOCOL_VERSION);
ss << *this;
return Hash(ss.begin(), ss.end());
Copy link
Contributor

Choose a reason for hiding this comment

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

We should use the fingerprint defined in ZIP 32, for consistency: BLAKE2b-256("ZcashSaplingFVFP", fvk)

CBLAKE2bWriter ss(SER_GETHASH, 0, ZCASH_SAPLING_FVFP_PERSONALIZATION);
ss << *this;
return ss.GetHash();

if(!DecryptSecret(vMasterKey, vchCryptedSecret, fvk.GetHash(), vchSecret))
return false;

if (vchSecret.size() != libzcash::SerializedSpendingKeySize)
Copy link
Contributor

Choose a reason for hiding this comment

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

This is technically incorrect, because it's the Sprout spending key size. But in practice both Sprout and Sapling spending keys serialize to the same size. If another reviewer wants it changed, I'll support that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will add const size_t SerializedSaplingSpendingKeySize = 32; and use that, for clarity

@@ -340,7 +357,7 @@ bool CCryptoKeyStore::AddSaplingSpendingKey(const libzcash::SaplingSpendingKey &
CKeyingMaterial vchSecret(ss.begin(), ss.end());
auto address = sk.default_address();
Copy link
Contributor

Choose a reason for hiding this comment

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

This can be removed now.

@str4d str4d moved this from In Review to In Progress in Arborist Team Jul 13, 2018
@zkbot
Copy link
Contributor

zkbot commented Jul 13, 2018

☔ The latest upstream changes (presumably #3390) made this pull request unmergeable. Please resolve the merge conflicts.

@arcalinea
Copy link
Contributor Author

Addressed comments - review needed on Sapling key encryption in CCryptoKeyStore::EncryptKeys

@arcalinea arcalinea requested a review from str4d July 17, 2018 20:52
@arcalinea arcalinea moved this from In Progress to Review Backlog in Arborist Team Jul 17, 2018
@mdr0id mdr0id moved this from Review Backlog to In Review in Arborist Team Jul 18, 2018
@mdr0id mdr0id requested a review from gtank July 23, 2018 18:28
{
LOCK(cs_SpendingKeyStore);
if (!IsCrypted())
return CBasicKeyStore::GetSaplingSpendingKey(fvk, skOut);
Copy link
Contributor

@ebfull ebfull Jul 25, 2018

Choose a reason for hiding this comment

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

I'm confused about what this calls, is this not recursing? unconfused

Copy link
Contributor

Choose a reason for hiding this comment

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

No, it's a superclass call.

READWRITE(ak);
READWRITE(nk);
READWRITE(ovk);
}

//! Get the 256-bit SHA256d hash of this full viewing key.
Copy link
Contributor

Choose a reason for hiding this comment

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

Update this comment to match the implementation and ZIP 32.

READWRITE(ak);
READWRITE(nk);
READWRITE(ovk);
}

//! Get the 256-bit SHA256d hash of this full viewing key.
uint256 GetHash() const;
Copy link
Contributor

Choose a reason for hiding this comment

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

Rename this to GetFingerprint() to match ZIP 32.

@str4d
Copy link
Contributor

str4d commented Aug 1, 2018

I'm taking over this PR, as @arcalinea is away this week.

@str4d str4d assigned str4d and unassigned arcalinea Aug 1, 2018
@str4d
Copy link
Contributor

str4d commented Aug 1, 2018

Rebased on master, addressed my comments, and added a few missing parts.

@zkbot try

@zkbot
Copy link
Contributor

zkbot commented Aug 1, 2018

⌛ Trying commit 37de067 with merge 068314e...

zkbot added a commit that referenced this pull request Aug 1, 2018
Add Sapling have/get spendingkey crypter overrides

Sapling crypter overrides for:
- `HaveSaplingSpendingKey()`
- `GetSaplingSpendingKey()`

Closes #3389
@zkbot
Copy link
Contributor

zkbot commented Aug 1, 2018

💔 Test failed - pr-try

@str4d str4d dismissed their stale review August 3, 2018 00:05

I've taken over the PR, so I can't review it.

daira
daira previously requested changes Aug 3, 2018
Copy link
Contributor

@daira daira left a comment

Choose a reason for hiding this comment

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

Renaming changes requested. (Some of my comments are on individual commits.)

libzcash::SaplingSpendingKey& sk)
{
CKeyingMaterial vchSecret;
if(!DecryptSecret(vMasterKey, vchCryptedSecret, fvk.GetFingerprint(), vchSecret))
Copy link
Contributor

Choose a reason for hiding this comment

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

nit: if (

if (vchSecret.size() != libzcash::SerializedSaplingSpendingKeySize)
return false;

CSecureDataStream ss(vchSecret, SER_NETWORK, PROTOCOL_VERSION);
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this actually dependent on the network protocol version? That doesn't sound right to me.

Copy link
Contributor

Choose a reason for hiding this comment

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

It matches what we do in e.g. src/key_io.h. The distinction from upstream, as I understand it, is that anything that might get communicated spatially between nodes is technically part of the protocol, whereas anything that is only communicated temporally between a single node's past and future selves is SER_DISK, CLIENT_VERSION.

Copy link
Contributor

Choose a reason for hiding this comment

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

I think this is questionable because, if we were to substantially change the network protocol, that would have to be versioned and upgraded quite differently from changing the external key formats. In any case, it's ok for this PR.

{
LOCK(cs_SpendingKeyStore);
if (!IsCrypted())
return CBasicKeyStore::GetSaplingSpendingKey(fvk, skOut);
Copy link
Contributor

Choose a reason for hiding this comment

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

No, it's a superclass call.

@@ -19,6 +19,8 @@ const size_t SerializedPaymentAddressSize = 64;
const size_t SerializedViewingKeySize = 64;
const size_t SerializedSpendingKeySize = 32;
Copy link
Contributor

Choose a reason for hiding this comment

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

These should be renamed to SerializedSprout....

@@ -173,7 +173,7 @@ bool CCryptoKeyStore::SetCrypted()
LOCK2(cs_KeyStore, cs_SpendingKeyStore);
if (fUseCrypto)
return true;
if (!(mapKeys.empty() && mapSpendingKeys.empty()))
if (!(mapKeys.empty() && mapSpendingKeys.empty() && mapSaplingSpendingKeys.empty()))
Copy link
Contributor

Choose a reason for hiding this comment

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

mapSpendingKeys should be renamed to mapSproutSpendingKeys.

Copy link
Contributor

Choose a reason for hiding this comment

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

I was hoping to avoid that large rename for now, but I'll go rip off the plaster 😂

Copy link
Contributor

Choose a reason for hiding this comment

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

Oh, turns out it's not a large rename after all!

@@ -999,14 +999,16 @@ class CWallet : public CCryptoKeyStore, public CValidationInterface
bool RemoveViewingKey(const libzcash::SproutViewingKey &vk);
//! Adds a viewing key to the store, without saving it to disk (used by LoadWallet)
bool LoadViewingKey(const libzcash::SproutViewingKey &dest);
Copy link
Contributor

Choose a reason for hiding this comment

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

These methods should be renamed to include Sprout.

@str4d
Copy link
Contributor

str4d commented Aug 3, 2018

Addressed @daira's comments.

@ebfull
Copy link
Contributor

ebfull commented Aug 3, 2018

re-ACK

@daira daira dismissed their stale review August 3, 2018 08:04

addressed

@daira
Copy link
Contributor

daira commented Aug 3, 2018

And rename these too (sorry I didn't catch them before):

     //! Add a spending key to the store.
     virtual bool AddSpendingKey(const libzcash::SproutSpendingKey &sk) =0;
 
     //! Check whether a spending key corresponding to a given payment address is present in the store.
     virtual bool HaveSpendingKey(const libzcash::SproutPaymentAddress &address) const =0;
     virtual bool GetSpendingKey(const libzcash::SproutPaymentAddress &address, libzcash::SproutSpendingKey& skOut) const =0;
     virtual void GetPaymentAddresses(std::set<libzcash::SproutPaymentAddress> &setAddress) const =0;

Also GetPaymentAddresses -> GetSproutPaymentAddresses
@str4d
Copy link
Contributor

str4d commented Aug 3, 2018

@daira Done (that was the big one).

Copy link
Contributor

@daira daira left a comment

Choose a reason for hiding this comment

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

ut(ACK+cov).

@ebfull
Copy link
Contributor

ebfull commented Aug 3, 2018

re-ACK

@str4d
Copy link
Contributor

str4d commented Aug 3, 2018

@zkbot r+

@zkbot
Copy link
Contributor

zkbot commented Aug 3, 2018

📌 Commit 25d5e80 has been approved by str4d

zkbot added a commit that referenced this pull request Aug 3, 2018
Update CCryptoKeyStore with Sapling support

Sapling crypter overrides for various `CCryptoKeyStore` functions such as:
- `HaveSaplingSpendingKey()`
- `GetSaplingSpendingKey()`

Also includes some changes to prepare for diversified addresses and ZIP 32.

Closes #3389
@zkbot
Copy link
Contributor

zkbot commented Aug 3, 2018

⌛ Testing commit 25d5e80 with merge aa32786...

@zkbot
Copy link
Contributor

zkbot commented Aug 3, 2018

☀️ Test successful - pr-merge
Approved by: str4d
Pushing aa32786 to master...

@zkbot zkbot merged commit 25d5e80 into zcash:master Aug 3, 2018
Arborist Team automation moved this from In Review to Released (Merged in Master) Aug 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-wallet Area: Wallet NU1-sapling Network upgrade: Sapling-specific tasks
Projects
Arborist Team
  
Released (Merged in Master)
Development

Successfully merging this pull request may close these issues.

None yet

5 participants