- BITCOIN SIGNATURE MALFORMED BASE64 ENCODING VERIFICATION
- BITCOIN SIGNATURE MALFORMED BASE64 ENCODING SOFTWARE
As the text is big, the signature is the decryption of the hash of this text. Wright claimed that he provided a signature on a large file, a text from Sartre. It's, as someone suggested, like to cut out the last page from a contract, paste it to another contract and claim the new contract is ok.
Craig Wright has recovered an old (and real) Satoshi's signature and tried to provide it as a new signature to validate his identity. The scam is not based on a cryptographic attak but on what is signed.
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.Short version: the signature is correct, it is a real signature and therefore it is possible to verify it with one's favourite software. 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)
