mirrors/core-lightning
1
0
Fork 0
mirror of https://github.com/ElementsProject/lightning.git synced 2025-02-22 22:45:27 +01:00
Code Issues Projects Releases Wiki Activity
core-lightning/bitcoin/privkey.h

20 lines
552 B
C
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>
2015-06-26 11:54:07 +09:30
#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>
2016-01-22 06:38:08 +10:30
#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>
2015-06-26 11:54:07 +09:30
#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't define it any more! Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-07-04 15:00:02 +09:30
#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 <rusty@rustcorp.com.au>
2015-06-26 11:54:07 +09:30
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 <rusty@rustcorp.com.au>
2017-05-06 11:49:44 +09:30
/* 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't do this currently outside tests, but we're about to. The tests to prove this as constant time are the tricky bit. Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
2018-08-17 13:46:34 +09:30
/* 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 <rusty@rustcorp.com.au>
2017-05-06 11:49:44 +09:30
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>
2015-06-26 11:54:07 +09:30
/* 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 <rusty@rustcorp.com.au>
2017-05-06 11:49:44 +09:30
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 <rusty@rustcorp.com.au>
2015-06-26 11:54:07 +09:30
};
#endif /* LIGHTNING_BITCOIN_PRIVKEY_H */
Reference in a new issue Copy permalink