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

Documentation: validatePrivateKey does not check typed array length

webmaster128 opened this issue · comments

  • I'm submitting a ...
    [x] bug report
    [ ] feature request
    [ ] question about the decisions made in the repository
    [ ] question about how to use this project

  • Summary

Right now, I get positive feedback from validatePrivateKey for the input values

  • e4ade2a5232a7c6f37e7b854a774e25e6047ee7c6d63e8304ae04fa190bc17 (31 bytes)
  • e4ade2a5232a7c6f37e7b854a774e25e6047ee7c6d63e8304ae04fa190bc1732aa (33 bytes)

so it looks like in all the stack of validatePrivateKey, the input length is not checked.

  • Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. StackOverflow, personal fork, etc.)

Hey @webmaster128, thanks for opening an issue!

Thanks, I should improve the documentation on validatePrivateKey to clarify the functionality there. There's a short note here on it – basically, I want to avoid adding any runtime checks which aren't necessary for 100% of consumers.

For most applications, when a potential new key is generated, it should be 32 bytes in length, so also validating the length in validatePrivateKey would be extraneous.

Ideally, TypeScript will eventually support stronger type guarantees about the length of a typed array so our function signature can specifically require a 32-byte Uint8Array (microsoft/TypeScript#18471). This would never be an error at runtime, because the compiler should be able to catch any instance in which the programmer accidentally generated the wrong size key (or failed to validate the length of a user-provided key), and those errors should never make it to runtime.

👍 makes sense, thanks. If I know that, I can easily do the check in my own code.

Merging into #3, which I think probably handles this best.