- #BITCOIN SIGNATURE MALFORMED BASE64 ENCODING VERIFICATION#
- #BITCOIN SIGNATURE MALFORMED BASE64 ENCODING SOFTWARE#
If you have no alternative suitable "funny" characters to choose from (perhaps all the other characters are invalid leaving only the 62 alphanumeric characters to choose from), you can always use an escape character for a very slight (~3/64?) increase in size. Skeet points out, find an existing library with enough flexibility. While base64 encoder/decoders are trivial, replacement subsitution can be done in a simple pre/post processing step of an existing base64 encode/decode functions (inside wrappers) - no need to re-invent the wheel (entirely). Consider some other variants: base64 Variant table from Wikipedia.
#BITCOIN SIGNATURE MALFORMED BASE64 ENCODING SOFTWARE#
Anyway, the lack of distinction between wrong key and wrong signature is indeed to allow future extensibility with a signature format that uses key reconstruction.Īny other opinions about the use of key reconstruction? I have little respect for software patents, but I prefer avoiding potential legal trouble for bitcoin too.Pick your replacements. I haven't looked into the patent itself, so it may not be applicable here, but for a simple signature string it may not matter that much. I avoided this here because key reconstruction from signatures depends on point compression, which is patented. This improvement would mean that checking the address matches the inferred public key would be the sole test of validity. I recall that one can infer the public key from a signature so we could shorten the signatures by 65 bytes or 87 base-64 characters by not bothering to encode the public key. Also with little extra effort, we can tell if the base-64 encoding is malformed and we might as well report this fact to the user rather than throw the information away and amalgamate the two error conditions under the "verification failed" umbrella.Īlso, I notice that the verifymessage doesn't help the user to distinguish between the signature failing because the address doesn't match the signature's public key and the ECDSA signature being invalid.
Most instances of corruption or truncation can be quickly detected by a strict format base-64 decoder before performing the much slower signature verification.
#BITCOIN SIGNATURE MALFORMED BASE64 ENCODING VERIFICATION#
In most practical situations I can imagine, the signature verification is likely to fail because the base-64 encoded string has become corrupted or truncated. It's probably sensible to tolerate variation as much as possible. I don't see what was wrong with "Padding text - " which was in the original version. I'd also change vchMessageMagic = ParseHex("3a4f40f998736d6f") to something more obviously not engineered to facilitate some cunning attack. If this "strict format check" is adopted then one should also check that an "=" character caused the loop termination. It's probably worth changing DecodeBase64 to throw a "malformed base-64 encoding" exception if "left" is not zero when exiting the while(1) loop. The base-64 values for "l", "m" and "n" only differ in the last two bits but "o" encodes 101000 2 which changes the value of the bytes to which the base-64 string decodes and thus the signature fails. As you can see, the last two bits are zeroes. The last base-64 value in the string is "k" which encodes 36 = 100100 2. On converting the bytes to base-64, the value of the two extra bits has to be arbitrarily specified as 0 and on decoding the two bits are thrown away. 137 bytes contains 1096 bitsīut 183 base-64 characters encode 1098 bits. This means it encodes floor(183*3/4) = 137 bytes. The base-64 string you provide is 183 characters long.
If I change a bit (but not too much) the second part of the signature (not the pub key, which is at the beginning), for example, by replacing a 'x' by a 'y' or 'z', verifymessage still validates it.
0 kommentar(er)
