![]() ![]() 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 verificationIn 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |