fix(strkey): bound decodeCheck input length before base32 decode

[Ryang-21]

What

decodeCheck now validates the encoded string's length against the requested strkey type before it decodes anything. Each type has a legal encoded length — 56 characters for G/S/T/X/C/L, 58 for B, 69 for M, and a 56–165 range for the variable-length P — and an input outside that range throws invalid encoded string length immediately. The unknown-version-byte-name check moved up alongside it, so a bad type name is also rejected before any decoding work. The per-type length table lives in a new encodedLengthRange helper; isValid no longer duplicates it and relies on decodeCheck throwing instead.

Why

The length check used to live only in isValid, so the two ways of reaching decodeCheck directly — calling the exported function, and SignerKey.decodeAddress — had no bound on their input at all. That had two consequences.

First, an attacker-supplied string of arbitrary length drove a full base32 decode plus a canonical re-encode comparison before anything rejected it. A megabyte-long G... string did a megabyte of work to produce an error that its second character already implied.

Second, and worse, a strkey with a valid version byte and a correct CRC16 but a wrong-sized payload decoded successfully and returned a mis-sized buffer. A 37-byte payload encoded as an ed25519PublicKey strkey came back as 37 bytes, and the caller only failed later, downstream, if it happened to check — isValid would have caught it, but nothing on the direct path did. That case now throws.

One consumer-visible consequence: an input that was already invalid may now report a length error where it previously reported a checksum, version-byte, or base32-character error. The input is rejected either way, but anyone matching on the message text will see the new one. Two existing tests asserted the old base32 message for 58-character inputs and were updated.

encodedLengthRange has no default case, and the repo builds with strict and noImplicitReturns, so adding a strkey type will fail the build until the table covers it.

[Copilot]

Pull request overview

Bounds StrKey inputs before Base32 decoding to prevent unnecessary work and malformed payloads.

Changes:

• Adds per-type encoded-length validation.
• Adds regression tests and updates error expectations.
• Updates changelog and generated API references.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/base/strkey.ts	Adds encoded-length guards.
test/unit/base/strkey.test.ts	Tests guards and valid types.
docs/reference/core-keys.md	Updates generated source links.
CHANGELOG.md	Documents behavior change.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.