Repository navigation
Reject non-ASCII characters in Bech32 strings - #1375
Open
allenpiscitello wants to merge 1 commit into
Open
allenpiscitello wants to merge 1 commit into
allenpiscitello wants to merge 1 commit into
Conversation
BIP 173 requires every character of a Bech32 string to be US-ASCII in the range 33-126, and BIP 350 keeps that rule for Bech32m. Bech32Encoder.DecodeDataCore did not check it. It lowercased the string and converted it with the ASCII encoder, which keeps only the low byte of each character. A non-ASCII character whose low byte is a valid Bech32 character, such as U+0171 (low byte 0x71, 'q'), was decoded as that character with a valid checksum. ToLowerInvariant also maps some non-ASCII characters to ASCII, such as U+212A KELVIN SIGN to 'k'. DecodeDataCore now rejects any character outside 33-126 before the case check and the lowercasing. Blech32Encoder already had this check, but ran it on the converted bytes, so it now checks the characters instead.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BIP 173 says each character of a Bech32 string must be US-ASCII in the range 33-126, and BIP 350 keeps that rule for Bech32m.
Bech32Encoder.DecodeDataCorenever checks it. It lowercases the string, then turns it into bytes withASCIIEncoder.DecodeData, which keeps only the low byte of each character. So a non-ASCII character whose low byte is a valid Bech32 character decodes as that character. For example, U+0171 'ű' becomes 0x71 'q', andbcrt1űqqqqp399…decodes to the same witness program asbcrt1qqqqqp399…with a valid checksum.ToLowerInvariantgives a second path: U+212A KELVIN SIGN lowercases to 'k'. The BIP 173 and BIP 350 vectors with 0x20, 0x7F and 0x80 in the HRP also decode today. The existing test only rejects them because it changes a data character first.DecodeDataCorenow throws aFormatExceptionfor any character outside 33-126, before the case check and the lowercasing.Decode,DecodeDataRaw, segwit and taproot address parsing andNetwork.Parseall go through it.Blech32Encoderin NBitcoin.Altcoins already had this check, but it ran on the bytes after the ASCII conversion, so it had the same hole. It now checks the characters.I left
ASCIIEncoderalone. It is also used for the PSBT magic bytes, P2P command names and user agents, so making it strict would change behaviour well outside Bech32.New tests cover the out-of-range BIP 173 and BIP 350 vectors, the 'ű' alias of a regtest address (through the encoder and
BitcoinAddress.Create), a Kelvin sign in the HRP, and the 'ű' alias of a Liquid blinded address. They also check that the valid addresses still decode. The Bech32, address and Taproot tests pass on net10.0, except the ones that download bitcoind, which fail the same way without this change.🤖 Generated with Claude Code