mratsim
commented
4 years ago Adding more details in ECP_mul, it seems like e itself (the exponent in ECP_MUL and also the secret key) is corrupted on function entry.
Closed mratsim closed 4 years ago
mratsim
commented
4 years ago Adding more details in ECP_mul, it seems like e itself (the exponent in ECP_MUL and also the secret key) is corrupted on function entry.
mratsim
commented
4 years ago Adding some debug shows that it's not the calling convention
proc `$`*(a: BIG_384): string
proc mul*(a: var ECP_BLS381, b: BIG_384) {.inline.} =
## Multiply point ``a`` by big integer ``b``.
{.noSideEffect.}:
debugEcho "common.mul b: ", $b
ECP_BLS381_mul(addr a, b)
mratsim
commented
4 years ago So the garbage at the beginning may be hidden due to toHex(BIG_384) preprocessing
mratsim
commented
4 years ago Replacing
iterator validatorKeys*(conf: BeaconNodeConf): ValidatorPrivKey =
for validatorKeyFile in conf.validators:
try:
yield validatorKeyFile.load
except CatchableError as err:
warn "Failed to load validator private key",
file = validatorKeyFile.string, err = err.msg
for kind, file in walkDir(conf.localValidatorsDir):
if kind in {pcFile, pcLinkToFile} and
cmpIgnoreCase(".privkey", splitFile(file).ext) == 0:
try:
yield ValidatorPrivKey.init(readFile(file).string)
except CatchableError as err:
warn "Failed to load a validator private key", file, err = err.msgby
iterator validatorKeys*(conf: BeaconNodeConf): ValidatorPrivKey =
for validatorKeyFile in conf.validators:
try:
yield validatorKeyFile.load
except CatchableError as err:
warn "Failed to load validator private key",
file = validatorKeyFile.string, err = err.msg
for kind, file in walkDir(conf.localValidatorsDir):
if kind in {pcFile, pcLinkToFile} and
cmpIgnoreCase(".privkey", splitFile(file).ext) == 0:
try:
let privkey = ValidatorPrivKey.init(readFile(file).string)
debugEcho "iter: ", cast[array[7, uint64]](privkey)
except CatchableError as err:
warn "Failed to load a validator private key", file, err = err.msgsolves the issue
mratsim
commented
4 years ago fromBytes assumed that the output buffer parameter was zero-initialized.
Existing data was properly overwritten if the input bytes/string was lengthy enough. But if it was too short, only part of limbs were overwritten
This is fixed in #44, calling fromBytes now zeroInit the buffer.
A followup on #40 and another debugging session on https://github.com/status-im/nim-beacon-chain/pull/780
By instrumenting privToPub and ECP_MUL with
We get the following stacktrace after building beacon_node with
Trying to isolate this with the following test cases gives different result
Notice that the temporary variable
tfirst bits are not polluted.