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

Replace OpenSSL AES with ctaes-based version #7689

Merged
merged 12 commits into from Jun 1, 2016

Conversation

Projects
None yet
10 participants
@sipa
Member

sipa commented Mar 14, 2016

This is a version of #5949 with a constant-time, slow and simple AES implementation.

Performance on modern systems should be around 2-10 Mbyte/s (for short to larger messages), which is plenty for the needs of our wallet.

@sipa sipa changed the title from Replace OpenSSL AES with our own constant-time version (edit of #5949) to Replace OpenSSL AES with our own constant-time version Mar 14, 2016

@laanwj laanwj added this to the 0.13.0 milestone Mar 15, 2016

@@ -29,13 +29,12 @@ $(LIBLEVELDB) $(LIBMEMENV):
endif
BITCOIN_CONFIG_INCLUDES=-I$(builddir)/config
BITCOIN_INCLUDES=-I$(builddir) -I$(builddir)/obj $(BOOST_CPPFLAGS) $(LEVELDB_CPPFLAGS) $(CRYPTO_CFLAGS) $(SSL_CFLAGS)
BITCOIN_INCLUDES=-I$(builddir) -I$(builddir)/obj $(BDB_CPPFLAGS) $(BOOST_CPPFLAGS) $(LEVELDB_CPPFLAGS) $(CRYPTO_CFLAGS) $(SSL_CFLAGS)

This comment has been minimized.

@jonasschnelli

jonasschnelli Mar 15, 2016

Member

I guess this does not break the --disable-wallet non BDB compile option? Its probably empty if BDB was not found.

@jonasschnelli

jonasschnelli Mar 15, 2016

Member

I guess this does not break the --disable-wallet non BDB compile option? Its probably empty if BDB was not found.

This comment has been minimized.

@theuni

theuni Mar 17, 2016

Member

@jonasschnelli yep, just empty

@theuni

theuni Mar 17, 2016

Member

@jonasschnelli yep, just empty

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Mar 15, 2016

Member

Nice work!
Short code review utACK. Will test soon.

Member

jonasschnelli commented Mar 15, 2016

Nice work!
Short code review utACK. Will test soon.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Mar 16, 2016

Member

Made a small change: the RijndaelSetup function now uses no modulus or division operations anymore. All tests still pass.

Member

sipa commented Mar 16, 2016

Made a small change: the RijndaelSetup function now uses no modulus or division operations anymore. All tests still pass.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Mar 17, 2016

Member

Added more comments.

Member

sipa commented Mar 17, 2016

Added more comments.

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni Mar 17, 2016

Member

Thanks @sipa for the constant-time version!

Member

theuni commented Mar 17, 2016

Thanks @sipa for the constant-time version!

@gmaxwell

View changes

Show outdated Hide outdated src/crypto/aes.cpp
@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Mar 21, 2016

Member

Tested ACK (52e05be).
Verified test vectors, run tests on different platforms and setups.
Tested this PR with encrypted wallet.dat from master (and vice versa).

NOT tested/verified constant time behavior.

Member

jonasschnelli commented Mar 21, 2016

Tested ACK (52e05be).
Verified test vectors, run tests on different platforms and setups.
Tested this PR with encrypted wallet.dat from master (and vice versa).

NOT tested/verified constant time behavior.

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Mar 23, 2016

Contributor

Concept NACK

I don't think we should be using low-level crypto primitives code developed by us that has ~zero chance of being reviewed or used by anyone other than us. I don't care how good we think we are, thats just not a good practice.

Maybe stick this in libsecp256k1 instead?

Contributor

petertodd commented Mar 23, 2016

Concept NACK

I don't think we should be using low-level crypto primitives code developed by us that has ~zero chance of being reviewed or used by anyone other than us. I don't care how good we think we are, thats just not a good practice.

Maybe stick this in libsecp256k1 instead?

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Mar 24, 2016

Member

@petertodd the "go put it in another library" response has a verifiable history of killing useful progress here (see also continued use of the problematic and fairly scary openssl RNG), you wouldn't provide the same complaint for random "found on the internet" code that was demonstratively broken. Seems misplaced. We don't have any performance concerns for AES but in a generic library there would be performance concerns and a different construction might be called for.

Member

gmaxwell commented Mar 24, 2016

@petertodd the "go put it in another library" response has a verifiable history of killing useful progress here (see also continued use of the problematic and fairly scary openssl RNG), you wouldn't provide the same complaint for random "found on the internet" code that was demonstratively broken. Seems misplaced. We don't have any performance concerns for AES but in a generic library there would be performance concerns and a different construction might be called for.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Mar 24, 2016

Member
Member

sipa commented Mar 24, 2016

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 24, 2016

Member

I agree with @petertodd that ideally the code should be published separately from bitcoin as well.

This doesn't need to be a generic library. We'd like this code to be self-contained (and have a special requirement here) so using OpenSSL et al is not an option, and maintaining a new generic library is a lot of work and responsibility too.

But I can understand that some people would find a specific implementation of AES just for bitcoin core as risky. (And even though it's not used in consensus, nor anything network-facing, a bug in the wallet encryption would be a big deal.)

Did anyone check by comparing their code line by line with an alternate implementation?

Yes, people have done so.

Maybe stick this in libsecp256k1 instead?

Please no, that's scope creep for libsecp256k1. You're not trying to turn secp256k1 into a generic crypto library are you?

Member

laanwj commented Mar 24, 2016

I agree with @petertodd that ideally the code should be published separately from bitcoin as well.

This doesn't need to be a generic library. We'd like this code to be self-contained (and have a special requirement here) so using OpenSSL et al is not an option, and maintaining a new generic library is a lot of work and responsibility too.

But I can understand that some people would find a specific implementation of AES just for bitcoin core as risky. (And even though it's not used in consensus, nor anything network-facing, a bug in the wallet encryption would be a big deal.)

Did anyone check by comparing their code line by line with an alternate implementation?

Yes, people have done so.

Maybe stick this in libsecp256k1 instead?

Please no, that's scope creep for libsecp256k1. You're not trying to turn secp256k1 into a generic crypto library are you?

@luke-jr

This comment has been minimized.

Show comment
Hide comment
@luke-jr

luke-jr Mar 24, 2016

Member

There seems to be a case to make for a "Bitcoin non-consensus crypto" library with AES, SHA512, etc...

Member

luke-jr commented Mar 24, 2016

There seems to be a case to make for a "Bitcoin non-consensus crypto" library with AES, SHA512, etc...

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 24, 2016

Member

I think we should ask the question separately from where the code is, though:

Can we get any (independent, skilled) cryptographers to review this code? At least reviewing crypto code is a mostly one-time deal, after which it will (hardly) ever change.

Member

laanwj commented Mar 24, 2016

I think we should ask the question separately from where the code is, though:

Can we get any (independent, skilled) cryptographers to review this code? At least reviewing crypto code is a mostly one-time deal, after which it will (hardly) ever change.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Mar 24, 2016

Member

I'd already suggested sipa split out and convert to C before he posted it because this have have independent interest as is probably the smallest constant time implementation of AES I've seen, or at least the smallest that doesn't have embarrassingly bad performance-- so no objection there.

Member

gmaxwell commented Mar 24, 2016

I'd already suggested sipa split out and convert to C before he posted it because this have have independent interest as is probably the smallest constant time implementation of AES I've seen, or at least the smallest that doesn't have embarrassingly bad performance-- so no objection there.

@jonasschnelli

This comment has been minimized.

Show comment
Hide comment
@jonasschnelli

jonasschnelli Mar 24, 2016

Member

I'm happy to extract this PR as C code into a C89 compatible library. I have interest to use this for my SPV library project (https://github.com/libbtc/libbtc) and for a open source hardware wallet MCU codebase: https://github.com/digitalbitbox/mcu.

Member

jonasschnelli commented Mar 24, 2016

I'm happy to extract this PR as C code into a C89 compatible library. I have interest to use this for my SPV library project (https://github.com/libbtc/libbtc) and for a open source hardware wallet MCU codebase: https://github.com/digitalbitbox/mcu.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Mar 30, 2016

Member

I have had this code running on 104 cores for several days, running a test that feeds random input through encode and decode with random keys and compares it to AES-NI.

The current maximum long term rate for the wallet application of this code in the current network is roughly 7 decrypts per second of roughly 48 bytes. At the current speed of my test harness it means that I have tested the equivalent of the network's maximum rate for thirty one thousand years without finding a fault.

Mutation testing showed very very high error correlation, meaning that any error manually introduced in the software made every execution (or nearly every execution) wrong. (So far I have not found any candidate error that didn't have this effect though automated searching, though I wouldn't be totally shocked if there were one-- it's still the case that this codebase has very high error correlation).

Pieter has a new version which is a straightforward port to plain C89 with some minor cleanup and some size reductions I contributed (the code size is still larger than the smallest AES implementations I can find (which aren't constant time), but not enormously so). I'll soon update my testing harness to that code and continue. I've also now reviewed the C89 version pretty extensively.

Member

gmaxwell commented Mar 30, 2016

I have had this code running on 104 cores for several days, running a test that feeds random input through encode and decode with random keys and compares it to AES-NI.

The current maximum long term rate for the wallet application of this code in the current network is roughly 7 decrypts per second of roughly 48 bytes. At the current speed of my test harness it means that I have tested the equivalent of the network's maximum rate for thirty one thousand years without finding a fault.

Mutation testing showed very very high error correlation, meaning that any error manually introduced in the software made every execution (or nearly every execution) wrong. (So far I have not found any candidate error that didn't have this effect though automated searching, though I wouldn't be totally shocked if there were one-- it's still the case that this codebase has very high error correlation).

Pieter has a new version which is a straightforward port to plain C89 with some minor cleanup and some size reductions I contributed (the code size is still larger than the smallest AES implementations I can find (which aren't constant time), but not enormously so). I'll soon update my testing harness to that code and continue. I've also now reviewed the C89 version pretty extensively.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Mar 30, 2016

Member

Thanks for the thorough testing and reviewing @gmaxwell!

Member

laanwj commented Mar 30, 2016

Thanks for the thorough testing and reviewing @gmaxwell!

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak Mar 30, 2016

Member

Concept ACK

Member

btcdrak commented Mar 30, 2016

Concept ACK

@paveljanik

This comment has been minimized.

Show comment
Hide comment
@paveljanik

paveljanik Mar 30, 2016

Contributor

Concept ACK

Contributor

paveljanik commented Mar 30, 2016

Concept ACK

@sipa sipa changed the title from Replace OpenSSL AES with our own constant-time version to [WIP] Replace OpenSSL AES with ctaes-based version Mar 30, 2016

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Mar 30, 2016

Member

The constant time AES core code is now factored out to a new repository; for now, it's available at http://github.com/sipa/ctaes/

The pull request here has been updated to use a subtree of that project, with C++ wrappers around it.

The build code is very simple: ctaes does not have any configuration or own build system, so Bitcoin Core just builds it as part of its own process. I have not included ctaes's tests here for simplicity; the relevant AES C++ wrapper code does have its own tests though.

Member

sipa commented Mar 30, 2016

The constant time AES core code is now factored out to a new repository; for now, it's available at http://github.com/sipa/ctaes/

The pull request here has been updated to use a subtree of that project, with C++ wrappers around it.

The build code is very simple: ctaes does not have any configuration or own build system, so Bitcoin Core just builds it as part of its own process. I have not included ctaes's tests here for simplicity; the relevant AES C++ wrapper code does have its own tests though.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Mar 30, 2016

Member

I've marked it as WIP for now, as I'd like to get some review on the ctaes code first before moving to the separate repository.

Member

sipa commented Mar 30, 2016

I've marked it as WIP for now, as I'd like to get some review on the ctaes code first before moving to the separate repository.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Mar 31, 2016

Member

@sipa can you at least update to your latest code (even if not doing the subtree) just so people will not review the wrong thing?

Member

gmaxwell commented Mar 31, 2016

@sipa can you at least update to your latest code (even if not doing the subtree) just so people will not review the wrong thing?

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa Mar 31, 2016

Member

@gmaxwell Done. Not going to touch this PR or the sipa/ctaes master branch until there has been some review.

Member

sipa commented Mar 31, 2016

@gmaxwell Done. Not going to touch this PR or the sipa/ctaes master branch until there has been some review.

Squashed 'src/crypto/ctaes/' content from commit cd3c3ac
git-subtree-dir: src/crypto/ctaes
git-subtree-split: cd3c3ac31fac41cc253bf5780b55ecd8d7368545
crypter: shuffle Makefile so that crypto can be used by the wallet
Wallet must come before crypto, otherwise linking fails on some platforms.

Includes a tangentially-related general cleanup rather than making the Makefile
sloppier.
@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 13, 2016

Member

I think the CBC implementation should move to ctaes. It makes ctaes more useful (people shouldn't be using the raw AES block cipher without a mode of operation), and reduced custom-written crypto inside Core.

Member

sipa commented May 13, 2016

I think the CBC implementation should move to ctaes. It makes ctaes more useful (people shouldn't be using the raw AES block cipher without a mode of operation), and reduced custom-written crypto inside Core.

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni May 13, 2016

Member

@sipa makes sense, sgtm. No hard feelings if you'd prefer to drop this stuff. I could port it to c and give it an api in ctaes if you'd like, though obviously the "i tried to make it constant-time" implementation will need a stronger guarantee :)

Member

theuni commented May 13, 2016

@sipa makes sense, sgtm. No hard feelings if you'd prefer to drop this stuff. I could port it to c and give it an api in ctaes if you'd like, though obviously the "i tried to make it constant-time" implementation will need a stronger guarantee :)

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 13, 2016

Member

@theuni No need for that to be a blocker, though. We could move things to C as a follow-up.

Member

sipa commented May 13, 2016

@theuni No need for that to be a blocker, though. We could move things to C as a follow-up.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 13, 2016

Member

Ready for merging, I hope.

Member

sipa commented May 13, 2016

Ready for merging, I hope.

@gmaxwell

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell May 14, 2016

Member

I didn't see any tests that explicit test for failure with invalid padding, except perhaps in the test that makes sure it behaves the same as OpenSSL. Perhaps if the CBC mode is ported to C in a later PR that could be addressed.

utACK. Good work sipa and cfields.

Member

gmaxwell commented May 14, 2016

I didn't see any tests that explicit test for failure with invalid padding, except perhaps in the test that makes sure it behaves the same as OpenSSL. Perhaps if the CBC mode is ported to C in a later PR that could be addressed.

utACK. Good work sipa and cfields.

@sipa sipa changed the title from [WIP] Replace OpenSSL AES with ctaes-based version to Replace OpenSSL AES with ctaes-based version May 14, 2016

AES256Decrypt::~AES256Decrypt()
{
memset(&ctx, 0, sizeof(ctx));

This comment has been minimized.

@pstratem

pstratem May 17, 2016

Contributor

Won't this just be optimized out?

@pstratem

pstratem May 17, 2016

Contributor

Won't this just be optimized out?

This comment has been minimized.

@theuni

theuni May 17, 2016

Member

@pstratem Probably, but it doesn't hurt to leave it here. We can replace it with something stronger when we figure out what to do about OPENSSL_cleanse.

@theuni

theuni May 17, 2016

Member

@pstratem Probably, but it doesn't hurt to leave it here. We can replace it with something stronger when we figure out what to do about OPENSSL_cleanse.

@btcdrak

This comment has been minimized.

Show comment
Hide comment
@btcdrak

btcdrak May 17, 2016

Member

For the record, the formal peer review was made of CTAES implementation correctness. The report can be found at http://bitcoin.sipa.be/ctaes/review.zip written by Ayo Akinyele.

Member

btcdrak commented May 17, 2016

For the record, the formal peer review was made of CTAES implementation correctness. The report can be found at http://bitcoin.sipa.be/ctaes/review.zip written by Ayo Akinyele.

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 25, 2016

Member

@theuni @jonasschnelli Feel like testing/reviewing again after the update to use ctaes?

Member

sipa commented May 25, 2016

@theuni @jonasschnelli Feel like testing/reviewing again after the update to use ctaes?

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni May 26, 2016

Member

@sipa Thanks for the reminder, I'll test/ack again today. I'm not qualified to review ctaes itself, so I'll have to defer to Ayo Akinyele's review (which appears thorough).

Member

theuni commented May 26, 2016

@sipa Thanks for the reminder, I'll test/ack again today. I'm not qualified to review ctaes itself, so I'll have to defer to Ayo Akinyele's review (which appears thorough).

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni

theuni May 27, 2016

Member

@sipa Please grab a quick build change: theuni@723779c

After that: ACK

Member

theuni commented May 27, 2016

@sipa Please grab a quick build change: theuni@723779c

After that: ACK

@sipa

This comment has been minimized.

Show comment
Hide comment
@sipa

sipa May 27, 2016

Member

@theuni Merged in

Member

sipa commented May 27, 2016

@theuni Merged in

@theuni

This comment has been minimized.

Show comment
Hide comment
@theuni
Member

theuni commented Jun 1, 2016

ACK 723779c

@sipa sipa merged commit 723779c into bitcoin:master Jun 1, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

sipa added a commit that referenced this pull request Jun 1, 2016

Merge #7689: Replace OpenSSL AES with ctaes-based version
723779c build: Enumerate ctaes rather than globbing (Cory Fields)
34ed64a crypter: add tests for crypter (Cory Fields)
0a36b9a crypter: shuffle Makefile so that crypto can be used by the wallet (Cory Fields)
976f9ec crypter: add a BytesToKey clone to replace the use of openssl (Cory Fields)
9049cde crypter: hook up the new aes cbc classes (Cory Fields)
fb96831 crypter: constify encrypt/decrypt (Cory Fields)
1c391a5 crypter: fix the stored initialization vector size (Cory Fields)
daa3841 crypto: add aes cbc tests (Cory Fields)
27a212d crypto: add AES 128/256 CBC classes (Cory Fields)
6bec172 Add ctaes-based constant time AES implementation (Pieter Wuille)
a545127 Squashed 'src/crypto/ctaes/' content from commit cd3c3ac (Pieter Wuille)

codablock added a commit to codablock/dash that referenced this pull request Sep 16, 2017

Merge #7689: Replace OpenSSL AES with ctaes-based version
723779c build: Enumerate ctaes rather than globbing (Cory Fields)
34ed64a crypter: add tests for crypter (Cory Fields)
0a36b9a crypter: shuffle Makefile so that crypto can be used by the wallet (Cory Fields)
976f9ec crypter: add a BytesToKey clone to replace the use of openssl (Cory Fields)
9049cde crypter: hook up the new aes cbc classes (Cory Fields)
fb96831 crypter: constify encrypt/decrypt (Cory Fields)
1c391a5 crypter: fix the stored initialization vector size (Cory Fields)
daa3841 crypto: add aes cbc tests (Cory Fields)
27a212d crypto: add AES 128/256 CBC classes (Cory Fields)
6bec172 Add ctaes-based constant time AES implementation (Pieter Wuille)
a545127 Squashed 'src/crypto/ctaes/' content from commit cd3c3ac (Pieter Wuille)

codablock added a commit to codablock/dash that referenced this pull request Sep 19, 2017

Merge #7689: Replace OpenSSL AES with ctaes-based version
723779c build: Enumerate ctaes rather than globbing (Cory Fields)
34ed64a crypter: add tests for crypter (Cory Fields)
0a36b9a crypter: shuffle Makefile so that crypto can be used by the wallet (Cory Fields)
976f9ec crypter: add a BytesToKey clone to replace the use of openssl (Cory Fields)
9049cde crypter: hook up the new aes cbc classes (Cory Fields)
fb96831 crypter: constify encrypt/decrypt (Cory Fields)
1c391a5 crypter: fix the stored initialization vector size (Cory Fields)
daa3841 crypto: add aes cbc tests (Cory Fields)
27a212d crypto: add AES 128/256 CBC classes (Cory Fields)
6bec172 Add ctaes-based constant time AES implementation (Pieter Wuille)
a545127 Squashed 'src/crypto/ctaes/' content from commit cd3c3ac (Pieter Wuille)

codablock added a commit to codablock/dash that referenced this pull request Dec 22, 2017

Merge #7689: Replace OpenSSL AES with ctaes-based version
723779c build: Enumerate ctaes rather than globbing (Cory Fields)
34ed64a crypter: add tests for crypter (Cory Fields)
0a36b9a crypter: shuffle Makefile so that crypto can be used by the wallet (Cory Fields)
976f9ec crypter: add a BytesToKey clone to replace the use of openssl (Cory Fields)
9049cde crypter: hook up the new aes cbc classes (Cory Fields)
fb96831 crypter: constify encrypt/decrypt (Cory Fields)
1c391a5 crypter: fix the stored initialization vector size (Cory Fields)
daa3841 crypto: add aes cbc tests (Cory Fields)
27a212d crypto: add AES 128/256 CBC classes (Cory Fields)
6bec172 Add ctaes-based constant time AES implementation (Pieter Wuille)
a545127 Squashed 'src/crypto/ctaes/' content from commit cd3c3ac (Pieter Wuille)

@str4d str4d referenced this pull request Aug 4, 2018

Merged

ZIP 32 preparations #3447

zkbot added a commit to zcash/zcash that referenced this pull request Aug 4, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.

zkbot added a commit to zcash/zcash that referenced this pull request Aug 4, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.

zkbot added a commit to zcash/zcash that referenced this pull request Aug 5, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.

zkbot added a commit to zcash/zcash that referenced this pull request Aug 5, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.

zkbot added a commit to zcash/zcash that referenced this pull request Aug 5, 2018

Auto merge of #3447 - str4d:zip32-prep, r=str4d
ZIP 32 preparations

Includes Makefile changes cherry-picked from the following upstream PRs:

- bitcoin/bitcoin#7689
- bitcoin/bitcoin#10849

Part of #3380.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment