bitauth / libauth

An ultra-lightweight, zero-dependency TypeScript library for Bitcoin Cash, Bitcoin, and Bitauth applications.

Home Page:https://libauth.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add a verify:binaries task to check function results over time

bitjson opened this issue · comments

One nice property of both compilation outputs (both the secp256k1 build and the hashes build) is that their algorithms are supposed to be deterministic. So as long as we're fully testing both, consumers can be reasonably-sure that I haven't poisoned them. Probably the most important example: all produced signatures are themselves deterministic (both Schnorr and ECDSA signatures) so we can randomly test inputs to confirm they match expected outputs. This is done for the hashes too. The only current weakness is that currently, we're not testing against another BCH-style Schnorr implementation, so until we have something else there to test against, that could be subverted. (Not to mention, the implementation we're compiling from could be subverted itself. It has had far less review so far than the secp256k1 implementation.)

As long is we're aggressively, randomly testing inputs and validating outputs, most poisoning issues are likely to be discovered. Even if I did something like secretly leak some private key material after every 1,000,000 signatures, that can be detected in about 5 minutes of random testing.

So: we should add a verify:binaries task which runs random tests until it's stopped. Then if you're building an application which is likely to use these binaries millions of times, you can run a test for whatever length of time needed to guarantee accurate results for the duration of your use-case. If you've run the randomized tests for 10M signatures, you're safe to use the tested binary for up to that many signatures before re-initializing the WASM instance. (Assuming your inputs are cryptographically-random. If you're somehow signing non-uniformly-random message hashes, I could be more clever about hiding a leak – e.g. only after 1M signatures over message hashes in which the first 3 bits are 0. To catch that in random testing, you need an average of 1B signatures, which would take about 3.5 days on my machine. So if you're signing bitcoin block hashes, test that properly too.)

If we need to touch the binaries again, we'll make sure their deterministically built.