lukechilds
/
lightning
mirror of https://github.com/lukechilds/lightning.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
6975 Commits
55 Branches
107 Tags
38 MiB
Tree: 69040e5943
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '69040e5943'
${ noResults }
lightning/bitcoin/privkey.h

22 lines
576 B
Raw Normal View History

Use libsecp256k1 instead of openssl for crypto. We still use openssl for bignums (base58) and for ripemd. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
10 years ago
#ifndef LIGHTNING_BITCOIN_PRIVKEY_H
#define LIGHTNING_BITCOIN_PRIVKEY_H
header cleanup: sort include lines into alpha order, after config.h This makes merging easier in future. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
9 years ago
#include "config.h"
Use libsecp256k1 instead of openssl for crypto. We still use openssl for bignums (base58) and for ripemd. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
10 years ago
#include <ccan/short_types/short_types.h>
Update ccan/structeq. structeq() is too dangerous: if a structure has padding, it can fail silently. The new ccan/structeq instead provides a macro to define foo_eq(), which does the right thing in case of padding (which none of our structures currently have anyway). Upgrade ccan, and use it everywhere. Except run-peer-wire.c, which is only testing code and can use raw memcmp(): valgrind will tell us if padding exists. Interestingly, we still declared short_channel_id_eq, even though we didn&#39;t define it any more! Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
7 years ago
#include <ccan/structeq/structeq.h>
Use libsecp256k1 instead of openssl for crypto. We still use openssl for bignums (base58) and for ripemd. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
10 years ago
devtools: Minor cleanup of the onion command line tool Simplifying some operations, erroring in some cases and moving to global defines for constants. Suggested-by: Rusty Russell &lt;@rustyrussell&gt; Signed-off-by: Christian Decker &lt;decker.christian@gmail.com&gt;
6 years ago
#define PRIVKEY_LEN 32
struct secret: use everywhere. We alternated between using a sha256 and using a privkey, but there are numerous places where we have a random 32 bytes which are neither. This fixes many of them (plus, struct privkey is now defined in terms of struct secret). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
8 years ago
/* General 256-bit secret, which must be private. Used in various places. */
struct secret {
u8 data[32];
};
secret_eq: remove in favor of constant time variant. To be safe, we should never memcmp secrets. We don&#39;t do this currently outside tests, but we&#39;re about to. The tests to prove this as constant time are the tricky bit. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
6 years ago
/* You probably shouldn't compare secrets in non-const time! */
bool secret_eq_consttime(const struct secret *a, const struct secret *b);
struct secret: use everywhere. We alternated between using a sha256 and using a privkey, but there are numerous places where we have a random 32 bytes which are neither. This fixes many of them (plus, struct privkey is now defined in terms of struct secret). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
8 years ago
Use libsecp256k1 instead of openssl for crypto. We still use openssl for bignums (base58) and for ripemd. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
10 years ago
/* This is a private key. Keep it secret. */
struct privkey {
struct secret: use everywhere. We alternated between using a sha256 and using a privkey, but there are numerous places where we have a random 32 bytes which are neither. This fixes many of them (plus, struct privkey is now defined in terms of struct secret). Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
8 years ago
struct secret secret;
Use libsecp256k1 instead of openssl for crypto. We still use openssl for bignums (base58) and for ripemd. Signed-off-by: Rusty Russell &lt;rusty@rustcorp.com.au&gt;
10 years ago
};
#endif /* LIGHTNING_BITCOIN_PRIVKEY_H */