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

Add wallet privkey encryption. #232

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
10 participants
@TheBlueMatt
Contributor

TheBlueMatt commented May 17, 2011

This commit adds support for ekeys, or encrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.

Keys are encrypted with AES-256-CBC through OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using AES256 with 1000 rounds.

Each RPC command which requires the password in practice has an additional
parameter, namely that password. Due to the need to convert the types of
other parameters before sending them, users who do not use encryption (via
the -nocrypt option) will have to specify a blank string (or any string) as
the first parameter, followed by the command they currently use.

Whenever keying material (unencrypted private keys, the user's password, the
wallet's AES key) is stored unencrypted in memory, any reasonable attempt is
made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.

Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.

Thanks to jgarzik for the original patch and sipa for all his input.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt
Contributor

TheBlueMatt commented May 17, 2011

TheBlueMatt added some commits Jun 7, 2011

Add wallet privkey encryption.
This commit adds support for ekeys, or encrypted private keys, to the wallet.
All keys are stored in memory in their encrypted form and thus the passphrase
is required from the user to spend coins, or to create new addresses.

Keys are encrypted with AES-256-CBC through OpenSSL's EVP library. The key is
calculated via EVP_BytesToKey using AES256 with 1000 rounds.

When the user is attempting to call RPC functions which require the password
to unlock the wallet, an error will be returned unless they call
walletpassword <password> <time to keep key in memory> first.

A topupkeypool command has been added which tops up the users keypool
(requiring the password via walletpassword first).
keypoolsize has been added to the output of getinfo to show the user the
number of keys left before they need to specify their password and call
topupkeypool.

A walletpasswordchange <oldpassword> <newpassword> has been added to allow
the user to change their password via RPC.

Whenever keying material (unencrypted private keys, the user's password, the
wallet's AES key) is stored unencrypted in memory, any reasonable attempt is
made to mlock/VirtualLock that memory before storing the keying material.
This is not true in several (commented) cases where mlock/VirtualLocking the
memory is not possible.

Although encryption of private keys in memory can be very useful on desktop
systems (as some small amount of protection against stupid viruses), on an
RPC server, the password is entered fairly insecurely. Thus, the only main
advantage encryption has for RPC servers is for RPC servers that do not spend
coins, except in rare cases, eg. a webserver of a merchant which only receives
payment except for cases of manual intervention.

Thanks to jgarzik for the original patch and sipa for all his input.
@dizzyd

This comment has been minimized.

Show comment
Hide comment
@dizzyd

dizzyd Jun 14, 2011

I believe EVP_BytesToKey only uses the first eight bytes of that buffer for salt. The long string is unnecessary and makes the code more difficult to read.

dizzyd commented on src/crypter.cpp in 4b82ff1 Jun 14, 2011

I believe EVP_BytesToKey only uses the first eight bytes of that buffer for salt. The long string is unnecessary and makes the code more difficult to read.

This comment has been minimized.

Show comment
Hide comment
@gmaxwell

gmaxwell Jun 20, 2011

This is busted busted busted. With this code I can precompute likely bitcoin wallet passwords and apply it over and over again against every wallet I steal. I can even make a nice wallet rainbow table. You've misunderstood how salt works and what its for. You should be storing a nice long value in the wallet and making it unique for every user not just unique to bitcoin.

This strengthening is also woefully inadequate. It's hardly better than the 1000x MD5 used by mtgox's freebsd-md5 passwords, especially considering the nice opencl SHA-256 code bitcoin users have.

I recommend switching to a hardware resistant strengthening function like scrypt, and adding real salting: http://forum.bitcoin.org/index.php?topic=8728.40

gmaxwell replied Jun 20, 2011

This is busted busted busted. With this code I can precompute likely bitcoin wallet passwords and apply it over and over again against every wallet I steal. I can even make a nice wallet rainbow table. You've misunderstood how salt works and what its for. You should be storing a nice long value in the wallet and making it unique for every user not just unique to bitcoin.

This strengthening is also woefully inadequate. It's hardly better than the 1000x MD5 used by mtgox's freebsd-md5 passwords, especially considering the nice opencl SHA-256 code bitcoin users have.

I recommend switching to a hardware resistant strengthening function like scrypt, and adding real salting: http://forum.bitcoin.org/index.php?topic=8728.40

This comment has been minimized.

Show comment
Hide comment
@tcoppi

tcoppi Jun 22, 2011

gmaxwell is right, a constant salt is useless and provides a false sense of security. At the very least use a random, per-wallet 64-bit salt, and better still is using something like scrypt.

tcoppi replied Jun 22, 2011

gmaxwell is right, a constant salt is useless and provides a false sense of security. At the very least use a random, per-wallet 64-bit salt, and better still is using something like scrypt.

@dizzyd

This comment has been minimized.

Show comment
Hide comment
@dizzyd

dizzyd Jun 14, 2011

I'm not sure I follow why you make a copy of strKeyData versus just feeding that directly into EVP_BytesToKey via .c_str(). The string passed in (strKeyData) is already in unsecured memory -- the horse has left the barn so to speak.

dizzyd commented on src/crypter.cpp in 4b82ff1 Jun 14, 2011

I'm not sure I follow why you make a copy of strKeyData versus just feeding that directly into EVP_BytesToKey via .c_str(). The string passed in (strKeyData) is already in unsecured memory -- the horse has left the barn so to speak.

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Jun 14, 2011

Owner

Most of the code which calls SetKey (all I think) has strKeyData mlock'd, making this slightly more secure.

Owner

TheBlueMatt replied Jun 14, 2011

Most of the code which calls SetKey (all I think) has strKeyData mlock'd, making this slightly more secure.

@dizzyd

This comment has been minimized.

Show comment
Hide comment
@dizzyd

dizzyd Jun 14, 2011

As best I can tell, the value in chNotIV is discarded/not used -- why go through all this work of locking it into memory and clearing it afterwards. If it's not being used, it doesn't matter..does it?

dizzyd commented on src/crypter.cpp in 4b82ff1 Jun 14, 2011

As best I can tell, the value in chNotIV is discarded/not used -- why go through all this work of locking it into memory and clearing it afterwards. If it's not being used, it doesn't matter..does it?

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Jun 14, 2011

Owner

Yep, I think it doesnt...as the comment above says "(and be a bit over-careful to keep the IV that we don't even use out of swap)"
But, there may be some kind of crazy issue in the way OpenSSL does IV calculations that might sometime in the future make it worth it. Its only a couple more system calls in any case.

Owner

TheBlueMatt replied Jun 14, 2011

Yep, I think it doesnt...as the comment above says "(and be a bit over-careful to keep the IV that we don't even use out of swap)"
But, there may be some kind of crazy issue in the way OpenSSL does IV calculations that might sometime in the future make it worth it. Its only a couple more system calls in any case.

@dizzyd

This comment has been minimized.

Show comment
Hide comment
@dizzyd

dizzyd Jun 14, 2011

A constant would be more appropriate here.

dizzyd commented on src/crypter.cpp in 4b82ff1 Jun 14, 2011

A constant would be more appropriate here.

@gstarnberger

This comment has been minimized.

Show comment
Hide comment
@gstarnberger

gstarnberger Jun 14, 2011

Instead of using EVP_BytesToKey for key derivation I think scrypt (https://www.tarsnap.com/scrypt.html) should provide a somewhat better security against brute-force attacks.

gstarnberger commented Jun 14, 2011

Instead of using EVP_BytesToKey for key derivation I think scrypt (https://www.tarsnap.com/scrypt.html) should provide a somewhat better security against brute-force attacks.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Jun 14, 2011

Contributor

@sysfrog Im not sure. Though it may claim to be more secure, 1000 rounds on OpenSSL's algorithm is also very secure and I think I'd rather use a more common/well used/well analysed algorithm like OpenSSL's entire code base is.

Contributor

TheBlueMatt commented Jun 14, 2011

@sysfrog Im not sure. Though it may claim to be more secure, 1000 rounds on OpenSSL's algorithm is also very secure and I think I'd rather use a more common/well used/well analysed algorithm like OpenSSL's entire code base is.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Jun 14, 2011

Contributor

@dizzyd Ill take a look at updating to your other recommendations when I have a chance.

Contributor

TheBlueMatt commented Jun 14, 2011

@dizzyd Ill take a look at updating to your other recommendations when I have a chance.

@dizzyd

This comment has been minimized.

Show comment
Hide comment
@dizzyd

dizzyd Jun 14, 2011

re: the unused IV -- "may be some kind of crazy issue.." is not a logical argument. Being paranoid about security is good, but there needs to be some basis in reality for it. Otherwise, you wind up with a lot of code that doesn't do anything and may obscure what's really going on.

re: calls to SetKey mlocking -- if that's the case, then you really don't need to copy it to vchKey. All that serves to do is increase the number of copies of keys you have in memory and increases your attack surface.

Security-wise: careful, minimal code > paranoid code. B0.02 from a random coder. :)

dizzyd commented Jun 14, 2011

re: the unused IV -- "may be some kind of crazy issue.." is not a logical argument. Being paranoid about security is good, but there needs to be some basis in reality for it. Otherwise, you wind up with a lot of code that doesn't do anything and may obscure what's really going on.

re: calls to SetKey mlocking -- if that's the case, then you really don't need to copy it to vchKey. All that serves to do is increase the number of copies of keys you have in memory and increases your attack surface.

Security-wise: careful, minimal code > paranoid code. B0.02 from a random coder. :)

@witkamp

This comment has been minimized.

Show comment
Hide comment
@witkamp

witkamp Jun 14, 2011

Is there a reason you are not using a random salt?

witkamp commented Jun 14, 2011

Is there a reason you are not using a random salt?

@enmaku

This comment has been minimized.

Show comment
Hide comment
@enmaku

enmaku Jun 16, 2011

Contributor

witkamp:

Is there a reason you are not using a random salt?

Yeah, password data should be salted - I mean we DO already have a giant network of people with high-end GPUs and the drivers/software necessary to brute force such things ;)

Contributor

enmaku commented Jun 16, 2011

witkamp:

Is there a reason you are not using a random salt?

Yeah, password data should be salted - I mean we DO already have a giant network of people with high-end GPUs and the drivers/software necessary to brute force such things ;)

@gstarnberger

This comment has been minimized.

Show comment
Hide comment
@gstarnberger

gstarnberger Jun 16, 2011

@TheBlueMatt As far as I understand scrypt the main advantage over older techniques is that it not only adds computational complexity to calculate a given key from a password, but that each calculation also requires a given amount of RAM. So it's much harder to parallelize an attack with, e.g., an ASIC, as you would need lots of RAM to do so.

But I agree with you: There have been much more reviews of the SSL code base, and so the chance of critical errors in OpenSSL is much lower compared to scrypt.

gstarnberger commented Jun 16, 2011

@TheBlueMatt As far as I understand scrypt the main advantage over older techniques is that it not only adds computational complexity to calculate a given key from a password, but that each calculation also requires a given amount of RAM. So it's much harder to parallelize an attack with, e.g., an ASIC, as you would need lots of RAM to do so.

But I agree with you: There have been much more reviews of the SSL code base, and so the chance of critical errors in OpenSSL is much lower compared to scrypt.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Jun 16, 2011

Contributor

@witkamp mostly because it would be a pain to store. This patch already uses the public key as the IV for the encryption of each private key so any kind of brute force/dictionary attack is already ridiculously difficult, I dont see a major advantage to adding a random salt to be used for a given wallet (and then stored in the wallet) as to brute force a wallet, you already need to know some of the information in the wallet (namely the public keys). But maybe others disagree?

@sysfrog OK, so its agreed then that OpenSSL key derivation is probably the best way to go?

@dizzyd Still planning on updating with some of your original recommendations, but I'm on vacation atm and dont feel like doing much coding.

Contributor

TheBlueMatt commented Jun 16, 2011

@witkamp mostly because it would be a pain to store. This patch already uses the public key as the IV for the encryption of each private key so any kind of brute force/dictionary attack is already ridiculously difficult, I dont see a major advantage to adding a random salt to be used for a given wallet (and then stored in the wallet) as to brute force a wallet, you already need to know some of the information in the wallet (namely the public keys). But maybe others disagree?

@sysfrog OK, so its agreed then that OpenSSL key derivation is probably the best way to go?

@dizzyd Still planning on updating with some of your original recommendations, but I'm on vacation atm and dont feel like doing much coding.

@enmaku

This comment has been minimized.

Show comment
Hide comment
@enmaku

enmaku Jun 16, 2011

Contributor

@TheBlueMatt gotcha, didn't see the public key = IV bit but it makes sense and stops dictionary/BF attacks at least as well as a random salt so I'm happy with it as a solution.

Contributor

enmaku commented Jun 16, 2011

@TheBlueMatt gotcha, didn't see the public key = IV bit but it makes sense and stops dictionary/BF attacks at least as well as a random salt so I'm happy with it as a solution.

@dizzyd

This comment has been minimized.

Show comment
Hide comment
@dizzyd

dizzyd Jun 16, 2011

On Thu, Jun 16, 2011 at 11:24 AM, TheBlueMatt <
reply@reply.github.com>wrote:

@dizzyd Still planning on updating with some of your original
recommendations, but I'm on vacation atm and dont feel like doing much
coding.

No worries -- I read your last reply first and was confused. :)

D.

dizzyd commented Jun 16, 2011

On Thu, Jun 16, 2011 at 11:24 AM, TheBlueMatt <
reply@reply.github.com>wrote:

@dizzyd Still planning on updating with some of your original
recommendations, but I'm on vacation atm and dont feel like doing much
coding.

No worries -- I read your last reply first and was confused. :)

D.

@phantomcircuit

This comment has been minimized.

Show comment
Hide comment
@phantomcircuit

phantomcircuit Jun 19, 2011

It would be best to use AES128 and not AES256. The key schedule in AES256 is known to be weak.

http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

phantomcircuit commented Jun 19, 2011

It would be best to use AES128 and not AES256. The key schedule in AES256 is known to be weak.

http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

@jrmithdobbs

This comment has been minimized.

Show comment
Hide comment
@jrmithdobbs

jrmithdobbs Jun 20, 2011

Contributor

Please salt that passphrase properly as suggested in gmaxwell's forum post.

Contributor

jrmithdobbs commented Jun 20, 2011

Please salt that passphrase properly as suggested in gmaxwell's forum post.

@mutantmonkey

This comment has been minimized.

Show comment
Hide comment
@mutantmonkey

mutantmonkey Jun 21, 2011

@phantomcircuit That attack is effective against 11-round AES-256, but not full 14-round AES-256. It'd be better to increase the number of rounds (he recommends 28 or more in that article) used instead of using a smaller key size. There are plenty of attacks on AES-128 as well, many of which were published after that article was written.

mutantmonkey commented Jun 21, 2011

@phantomcircuit That attack is effective against 11-round AES-256, but not full 14-round AES-256. It'd be better to increase the number of rounds (he recommends 28 or more in that article) used instead of using a smaller key size. There are plenty of attacks on AES-128 as well, many of which were published after that article was written.

@TheBlueMatt

This comment has been minimized.

Show comment
Hide comment
@TheBlueMatt

TheBlueMatt Jun 26, 2011

Contributor

Closing this in anticipation of the new branch.

Contributor

TheBlueMatt commented Jun 26, 2011

Closing this in anticipation of the new branch.

dexX7 pushed a commit to dexX7/bitcoin that referenced this pull request Dec 11, 2014

sipa added a commit to sipa/bitcoin that referenced this pull request Apr 22, 2015

Squashed 'src/secp256k1/' changes from 1897b8e..22f60a6
22f60a6 Merge pull request #245
61c1b1e Merge pull request #190
d227579 Add scalar blinding and a secp256k1_context_randomize() call.
c146b4a Add bench_internal to gitignore.
9c4fb23 Add a secp256k1_fe_cmov unit test.
426fa52 Merge pull request #243
d505a89 Merge pull request #244
2d2707a travis: test i686 builds with gmp
cf7f702 travis: update to new build infrastructure
bb0ea50 Replace set/add with cmov in secp256k1_gej_add_ge.
f3d3519 Merge pull request #241
5c2a4fa Fix memory leak in context unit test
14aacdc Merge pull request #239
93226a5 secp256k1.c: Add missing DEBUG_CHECKs for sufficiently capable contexts
6099220 Merge pull request #237
6066bb6 Fix typo: avg -> max
9688030 Merge pull request #236
d899b5b Expose ability to deep-copy a context
3608c7f Merge pull request #208
a9b6595 [API BREAK] Introduce explicit contexts
a0d3b89 Merge pull request #233
9e8d89b Merge pull request #234
65e70e7 Merge pull request #235
5098f62 Improve documentation formatting consistency
4450e24 Add a comment about the avoidance of secret data in array indexes.
6534ee1 initialize variable
d5b53aa Merge pull request #232
c01df1a Avoid some implicit type conversions to make C++ compilers happy.
bfe96ba Merge pull request #231
33270bf Add a couple comments pointing to particular sections of RFC6979.
41603aa Merge pull request #230
2632019 Brace all the if/for/while.

git-subtree-dir: src/secp256k1
git-subtree-split: 22f60a6

dexX7 added a commit to dexX7/bitcoin that referenced this pull request Sep 18, 2015

Merge pull request #232
a9fa833 Add API documentation for "omni_listpendingtransactions" (dexX7)
5bebb81 Add new RPC to list unconfirmed Omni transactions (dexX7)

TheBlueMatt added a commit to TheBlueMatt/bitcoin that referenced this pull request Oct 20, 2015

Update secp256k1
This contains the following two merges, as well as a few other changes:

Squashed 'src/secp256k1/' changes from 22f60a6..18f9f08

18f9f08 Pedersen commitments, borromean ring signatures, and ZK range proofs.
5161227 Add benchmark for ECDH multiplication
c40cb72 Expose API for constant time point multiplication
40adc7a Add constant-time `secp256k1_ecdh_point_multiply` for ECDH
ff9a397 Add zero/one tests to ecmult
729badf Merge pull request #210
2d5a186 Apply effective-affine trick to precomp
4f9791a Effective affine addition in EC multiplication

git-subtree-dir: src/secp256k1
git-subtree-split: 18f9f0821c5a7795b760763c99d545af96a22775

Squashed 'src/secp256k1/' changes from b0210a9..22f60a6

22f60a6 Merge pull request #245
61c1b1e Merge pull request #190
d227579 Add scalar blinding and a secp256k1_context_randomize() call.
c146b4a Add bench_internal to gitignore.
9c4fb23 Add a secp256k1_fe_cmov unit test.
426fa52 Merge pull request #243
d505a89 Merge pull request #244
2d2707a travis: test i686 builds with gmp
cf7f702 travis: update to new build infrastructure
bb0ea50 Replace set/add with cmov in secp256k1_gej_add_ge.
f3d3519 Merge pull request #241
5c2a4fa Fix memory leak in context unit test
14aacdc Merge pull request #239
93226a5 secp256k1.c: Add missing DEBUG_CHECKs for sufficiently capable contexts
6099220 Merge pull request #237
6066bb6 Fix typo: avg -> max
9688030 Merge pull request #236
d899b5b Expose ability to deep-copy a context
3608c7f Merge pull request #208
a9b6595 [API BREAK] Introduce explicit contexts
a0d3b89 Merge pull request #233
9e8d89b Merge pull request #234
65e70e7 Merge pull request #235
5098f62 Improve documentation formatting consistency
4450e24 Add a comment about the avoidance of secret data in array indexes.
6534ee1 initialize variable
d5b53aa Merge pull request #232
c01df1a Avoid some implicit type conversions to make C++ compilers happy.
bfe96ba Merge pull request #231
33270bf Add a couple comments pointing to particular sections of RFC6979.
41603aa Merge pull request #230
2632019 Brace all the if/for/while.
1897b8e Merge pull request #229
efc571c Add simple testcases for signing with rfc6979 extra entropy.
1573a10 Add ability to pass extra entropy to rfc6979
3087bc4 Merge pull request #228
d9b9f11 Merge pull request #218
0065a8f Eliminate multiple-returns from secp256k1.c.
354ffa3 Make secp256k1_ec_pubkey_create reject oversized secrets.
27bc131 Silence some warnings from pedantic static analysis tools, improve compatibility with C++.
3b7ea63 Merge pull request #221
f789c5b Merge pull request #215
4bc273b Merge pull request #222
137a8ec Merge pull request #216
7c3771d Disable overlength-strings warnings.
8956111 use 128-bit hex seed
02efd06 Use RFC6979 for test PRNGs
ae55e85 Use faster byteswapping and avoid alignment-increasing casts.
443cd4b Get rid of hex format and some binary conversions
0bada0e Merge #214: Improve signing API documentation & specification
8030d7c Improve signing API documentation & specification
7b2fc1c Merge #213: Removed gotos, which are hard to trace and maintain.
11690d3 Removed gotos, which are hard to trace and maintain.
122a1ec Merge pull request #205
035406d Merge pull request #206
2d4cd53 Merge pull request #161
34b898d Additional comments for the testing PRNG and a seeding fix.
6efd6e7 Some comments explaining some of the constants in the code.
ffccfd2 x86_64 assembly optimization for scalar_4x64
67cbdf0 Merge pull request #207
039723d Benchmarks for all internal operations
6cc8425 Include a comment on secp256k1_ecdsa_sign explaining low-s.
f88343f Merge pull request #203
d61e899 Add group operation counts
2473f17 Merge pull request #202
b5bbce6 Some readme updates, e.g. removal of the GMP field.
f0d851e Merge pull request #201
a0ea884 Merge pull request #200
f735446 Convert the rest of the codebase to C89.
bf2e1ac Convert tests to C89. (also fixes a use of bare "inline" in field)
fc8285f Merge pull request #199
fff412e Merge pull request #197
4be8d6f Centralize the definition of uint128_t and use it uniformly.
d9543c9 Switch scalar code to C89.
fcc48c4 Remove the non-storage cmov
55422b6 Switch ecmult_gen to use storage types
41f8455 Use group element storage type in EC multiplications
e68d720 Add group element storage type
ff889f7 Field storage type
7137be8 Merge pull request #196
0768bd5 Get rid of variable-length hex string conversions
e84e761 Merge pull request #195
792bcdb Covert several more files to C89.
45cdf44 Merge pull request #193
17db09e Merge pull request #194
402878a fix ifdef/ifndef
25b35c7 Convert field code to strict C89 (+ long long, +__int128)
3627437 C89 nits and dead code removal.
a9f350d Merge pull request #191
4732d26 Convert the field/group/ecdsa constant initialization to static consts
19f3e76 Remove unused secp256k1_fe_inner_{start, stop} functions
f1ebfe3 Convert the scalar constant initialization to static consts
50cc6ab Merge pull request #178
941e221 Add tests for handling of the nonce function in signing.
10c81ff Merge pull request #177
7688e34 Add magnitude limits to secp256k1_fe_verify to ensure that it's own tests function correctly.
4ee4f7a Merge pull request #176
70ae0d2 Use secp256k1_fe_equal_var in secp256k1_fe_sqrt_var.
7767b4d Merge pull request #175
9ab9335 Add a reference consistency test to ge_tests.
60571c6 Rework group tests
d26e26f Avoid constructing an invalid signature with probability 1:2^256.
b450c34 Merge pull request #163
d57cae9 Merge pull request #154
49ee0db Add _normalizes_to_zero_var variant
eed599d Add _fe_normalizes_to_zero method
d7174ed Weak normalization for secp256k1_fe_equal
0295f0a weak normalization
bbd5ba7 Use rfc6979 as default nonce generation function
b37fbc2 Implement SHA256 / HMAC-SHA256 / RFC6979.
c6e7f4e [API BREAK] Use a nonce-generation function instead of a nonce
cf0c48b Merge pull request #169
603c33b Make signing fail if a too small buffer is passed.
6d16606 Merge pull request #168
7277fd7 Remove GMP field implementation
e99c4c4 Merge pull request #123
13278f6 Add explanation about how inversion can be avoided
ce7eb6f Optimize verification: avoid field inverse
a098f78 Merge pull request #160
38acd01 Merge pull request #165
6a59012 Make git ignore bench_recover when configured with benchmark enabled
1ba4a60 Configure options reorganization
3c0f246 Merge pull request #157
808dd9b Merge pull request #156
8dc75e9 Merge pull request #158
28ade27 build: nuke bashisms
5190079 build: use subdir-objects for automake
8336040 build: disable benchmark by default
bccaf86 Merge pull request #150
2a53a47 Merge pull request #151
5f5a31f Merge pull request #149
3907277 Merge pull request #142
a3e0611 Enable tests in x86 travis builds
45da235 x86 builder
8bb0e93 Merge pull request #155
971fe81 build: fix openssl detection for cross builds
f22d73e Explicitly access %0..%2 as 64-bit so we use the right registers for x32 ABI
e66d4d6 Avoid the stack in assembly and use explicit registers
cf7b2b4 Fix ECDSA message hashes to 32 bytes
056ad31 Really compile with -O3 by default
74ad63a Merge pull request #146
9000458 Merge pull request #145
1f46b00 build: fix __builtin_expect detection for clang
aaba2e0 Merge pull request #136
8a0775c Merge pull request #144
ee1eaa7 Merge pull request #141
c88e2b8 Compile with -O3 by default
6558a26 Make the benchmarks print out stats
000bdf6 Rename bench_verify to bench_recovery
7c6fed2 Add a few more additional tests.
992e03b travis: add clang to the test matrix
b43b79a Merge pull request #143
e06a924 Include time.h header for time().
8d11164 Add some additional tests.
3545627 Merge pull request #118
6a9901e Merge pull request #137
376b28b Merge pull request #128
1728806 Merge pull request #138
a5759c5 Check return value of malloc
39bd94d Variable time normalize
ad86bdf Merge pull request #140
54b768c Another redundant secp256k1_fe_normalize
69dcaab Merge pull request #139
1c29f2e Remove redundant secp256k1_fe_normalize from secp256k1_gej_add_ge_var.
2b9388b Remove unused secp256k1_fe_inv_all
f461b76 Allocate precomputation arrays on the heap
b2c9681 Make {mul,sqr}_inner use the same argument order as {mul,sqr}
6793505 Convert YASM code into inline assembly
f048615 Rewrite field assembly to match the C version
3ce74b1 Tweak precomputed table size for G

git-subtree-dir: src/secp256k1
git-subtree-split: 22f60a6

deadalnix pushed a commit to deadalnix/bitcoin that referenced this pull request Jan 19, 2017

Merge pull request #232
c01df1a Avoid some implicit type conversions to make C++ compilers happy. (Gregory Maxwell)

lateminer pushed a commit to lateminer/bitcoin that referenced this pull request Dec 9, 2017

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