[ecash-lib] Add SHA512 support, hashers and `Hmac`
ClosedPublic
Actions

Authored by tobias_ruck on Thu, Jan 30, 03:47.

Details

Reviewers

bytesofman

Group Reviewers

Restricted Project

Commits

rABC37bb5ed18b08: [ecash-lib] Add SHA512 support, hashers and `Hmac`

Summary

Hmac (hash-based message authentication code) is needed to support mnemonics (for PBKDF2) and HD wallets, such that ecash-lib can be used standalone without other packages to e.g. generate mnemonics and derive HD wallet paths.

For this, we need SHA512 support (HD wallets use it), and we add a simple Hmac class that allows successive updates.

In theory, we could use sha256 and sha512 themselves in the HMAC, however, this will be far too slow in PBKDF2.

Test Plan

npm test

Diff Detail

Repository

rABC Bitcoin ABC

Branch

ecash-lib-hmac

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 32254
Build 63998: Build Diff	ecash-lib-integration-tests · cashtab-tests · ecash-agora-integration-tests · ecash-lib-tests · ecash-agora-tests
Build 63997: arc lint + arc unit

Event Timeline

tobias_ruck created this revision.Thu, Jan 30, 03:47

Herald added a reviewer: Restricted Project. · View Herald TranscriptThu, Jan 30, 03:47

tobias_ruck requested review of this revision.Thu, Jan 30, 03:47

Harbormaster completed remote builds in B32254: Diff 52440.Thu, Jan 30, 03:54

tobias_ruck added a child revision: D17610: [ecash-lib] Add `pbkdf2`.Thu, Jan 30, 03:56

not necessarily related to the diff -- why is it better to keep all of these hash functions in webassembly? afaik we are the only cryptocurrency doing this.

BTC libs (bip32, bitcoinjs-lib, others) use tiny-secp256k1 (or BitGo uses @noble/secp256k1) -- looks like noble is where some of the tests here are modeled (https://github.com/paulmillr/noble-hashes/blob/main/test/hmac.test.js)

https://github.com/bitcoinjs/bip32
https://www.npmjs.com/package/tiny-secp256k1
https://www.npmjs.com/package/@noble/secp256k1

These all seem small and dependency free...and lose the whole initWasm() complication.

It's nice that we have more control using our own stuff, but the wasm in particular is a high friction dev thing.

What are the benefits?

I guess it makes us ... uniquely less vulnerable to supply chain attacks?

modules/ecash-lib/src/hmac.test.ts
15	no blocker as this is how it's done in all the other ecash-lib tests. it's probably better practice to use a `before` to do this though, as in beforeAll(async () => { await initWasm() }) .. though really, mb that is just extra code. I find it useful to keep it organized with `beforeAll` as perhaps there are multiple `describe` blocks in a single test file, perhaps not all of them need it. Or perhaps they all do, and the second one won't catch it from the `await` outside of any `beforeAll` in the first block. ultimately it is prob a syntax preference question