Pages:
Author

Topic: New Attack Vector - page 5. (Read 46611 times)

legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 09:25:54 AM
#34
Returning
Code:
ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa
because of a too low fee is rather strange
that makes sense.
so blockchain.info does not use bitcoind - I was always wondering..

@kokjo your tx won't get mined.
it does not like the fact that the 44 ( field) in your sig is not the actual sig length minus 3.
Code:
    if (vchSig[1] != vchSig.size()-3)
        return error("Non-canonical signature: wrong length marker");
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
July 17, 2013, 09:21:58 AM
#33
0100000001fd31efbac93daa8743525898e81ebcfc69988484ede77537369117112b03dfb500000 0006c49304402203ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37 022014247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c517300000121020 c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95ffffffff01e41f01 00000000001976a914b110cace3b1d8181df64854ddcf85bc635d10de888ac00000000
this one works for me as well, so its definitely a different issue than I had mentioned before.

maybe bitcoind just does not like your low 0.00000071 BTC fee?

Returning
Code:
ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa
because of a too low fee is rather strange
legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 09:17:41 AM
#32
0100000001fd31efbac93daa8743525898e81ebcfc69988484ede77537369117112b03dfb500000 0006c49304402203ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37 022014247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c517300000121020 c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95ffffffff01e41f01 00000000001976a914b110cace3b1d8181df64854ddcf85bc635d10de888ac00000000
this one works for me as well, so its definitely a different issue than I had mentioned before.

maybe bitcoind just does not like your low 0.00000071 BTC fee?
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 09:13:10 AM
#31
Would you mind posting the hex of the signed raw transaction?

I was just looking in script.spp, and this error is caused by an incorrect length.  When you attach your hashtype, are you changing the total length?

0x30  0x02 0x02
Code:
0100000001fd31efbac93daa8743525898e81ebcfc69988484ede77537369117112b03dfb5000000006c49304402203ccac0d763cea96b7eefcc8bb77083312d5f74f19f3f38a2ef7c09a56303ec37022014247484bc2e6f979ea783753b92751deff8ea69f488483c18349c92ee8c517300000121020c04fd79c0de8acaf84cf68c92b5a64357b83c7e8c5115ee17ca5179b2516b95ffffffff01e41f0100000000001976a914b110cace3b1d8181df64854ddcf85bc635d10de888ac00000000


why would i change the length, are bitcoin in the business of messing with other people's standard?
legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 09:05:18 AM
#30
there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:
Code:
0x30  0x02 0x02

it is taken using this expression:
Code:
unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

This distinction is only meaningful when the signature is not canonical.  When the signature is in the proper form, the last bye is the last byte.


I'm having a hard time understan what you are talking about here.  The SIGHASH values apply to signatures.  The txout being redeemed has no bearing on them.

Check this - it's a real signature from tx 67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2:

Code:
3045022052538ceefdadef44696559b5b135e48218403f10120bcf592825b924af804821022100ed30a2a2218ad85438fd6a38f909b5ac55bc322033b63ddf17b3b9db11cd61800001

Following the format, the hashtype should be 00, while in fact it is 01.
kjj
legendary
Activity: 1302
Merit: 1026
July 17, 2013, 09:00:25 AM
#29
there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:
Code:
0x30  0x02 0x02

it is taken using this expression:
Code:
unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

This distinction is only meaningful when the signature is not canonical.  When the signature is in the proper form, the last bye is the last byte.


I'm having a hard time understanding what you are talking about here.  The SIGHASH values apply to signatures.  The txout being redeemed has no bearing on them.
legendary
Activity: 2053
Merit: 1356
aka tonikt
July 17, 2013, 08:50:47 AM
#28
there is actually an issue that not everyone is aware of, though I don't know if it is the reason of your problem.

the hashtype byte is not taken using this format:
Code:
0x30  0x02 0x02

it is taken using this expression:
Code:
unsigned char nHashType = vchSig[vchSig.size() - 1] & (~(SIGHASH_ANYONECANPAY));

and you cannot fix it - it's buried deep inside the chain.
https://blockchain.info/tx/67e758b27df26ad609f943b30e5bbb270d835b737c8b3df1a7944ba08df8b9a2
kjj
legendary
Activity: 1302
Merit: 1026
July 17, 2013, 08:43:47 AM
#27
Would you mind posting the hex of the signed raw transaction?

I was just looking in script.spp, and this error is caused by an incorrect length.  When you attach your hashtype, are you changing the total length?

0x30  0x02 0x02
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 08:23:16 AM
#26
What's funny is that this very thread explains why non-canonical signatures are bad, and why we stopped accepting them.

Just out of curiosity, is openssl giving you a padded signature under normal circumstances, or are you going out of your way to make it give you garbage?
nope not at all, i give it the key(generated by the satoshi client, btw) and the transaction hash, it gives me the signature and i append hashtype.

blockchain.info accepts but bitcoind rejects.

you people should really stop implementing features, and sit down create a standard and start fix bitcoin instead.
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 08:19:37 AM
#25
blockchain.info accepts my transaction vis pushtx, but bitcoind does not find it aesthetically pleasing enough.

if bitcoin fails, the blame goes to the developers for not having a standard to implement, but making shit up as you go along.
kjj
legendary
Activity: 1302
Merit: 1026
July 17, 2013, 08:18:50 AM
#24
BITCOIN IS SHIT, it does not accept signatures from the most well know implementation of crypto algorithms: openssl.

Code:
ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa

why the fuck is this stuff implemented the way it is?

bitcoin and especially the satoshi client is a stinking pile faulty patches on other patches of bad and stupidly written code!

All main developers is bad at coding, and should feel bad about it.

/rant over

What's funny is that this very thread explains why non-canonical signatures are bad, and why we stopped accepting them.

Just out of curiosity, is openssl giving you a padded signature under normal circumstances, or are you going out of your way to make it give you garbage?
legendary
Activity: 1050
Merit: 1000
You are WRONG!
July 17, 2013, 08:03:28 AM
#23
BITCOIN IS SHIT, it does not accept signatures from the most well know implementation of crypto algorithms: openssl.

Code:
ThreadRPCServer method=sendrawtransaction
ERROR: Non-canonical signature: wrong length marker
ERROR: CScriptCheck() : f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa VerifySignature failed
ERROR: CTxMemPool::accept() : ConnectInputs failed f57a2c4d3b8f9653eaee0d5611fcf7c918bcc8903894e148c5b56486fb3f8eaa

why the fuck is this stuff implemented the way it is?

bitcoin and especially the satoshi client is a stinking pile faulty patches on other patches of bad and stupidly written code!

All main developers is bad at coding, and should feel bad about it.

/rant over
staff
Activity: 4242
Merit: 8672
October 04, 2012, 11:43:44 PM
#22
Now that this is well known, I have to point out the following:

Transaction malleability has been known and discussed many times— including padding and other encoding differences. Is there some reason that you believe the s-flip to have distinct implications from all of the other signature encoding differences?

The understood risk of this in prior discussions has primarily been that troublemakers could create confusion by changing the transaction ID of confirmed transactions to be something different than the transaction participants were expecting (so, e.g. they'd see two transactions doing the same thing, one which never confirms). There is a secondary risk that parasites could 'hijack' other people's transaction to pay the way to embed data in the blockchain for them.

Quote
I believe the originator wouldn't recognise the flipped transaction has spent his coins.

In the reference client the spent-ness of candidate inputs when drafting a transaction are checked with IsSpent(), the txid of the spending transaction should be irrelevant. Can you elaborate on what you're thinking here?
sr. member
Activity: 416
Merit: 277
October 04, 2012, 09:40:39 PM
#21
For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.
Now that this is well known, I have to point out the following:

If some subset of clients rebroadcast transactions while flipping the sign of s then the transactions have different ids (because currently the signatures are included when hashing to find the transaction ID) and there may be some problems if the flipped version makes it into the block instead of the vanilla version as I believe the originator wouldn't recognise the flipped transaction has spent his coins.

ByteCoin
hero member
Activity: 555
Merit: 654
October 04, 2012, 04:26:46 PM
#20
For the record, there is another possibility of signature malleability.

For every ECDSA signature (r,s), the signature (r, -s (mod N)) is a valid signature of the same message. Note that the new signature has the same size as the original, as opposite as the malleabillity of padding.
hero member
Activity: 555
Merit: 654
August 22, 2012, 10:31:44 AM
#19
Thank you Sipa and Gavin, I'll keep researching on this..
legendary
Activity: 1652
Merit: 2301
Chief Scientist
August 22, 2012, 09:22:50 AM
#18
Making transactions with non-DER-encoded (aka BER encoded) signatures non-standard has been on my TODO list for over a year now, but has never been the highest priority.  That's the first step to making non-DER-encoded signatures completely illegal.

Note that if there is a core-dumping bug in OpenSSL's decoding code then it needs to get fixed in OpenSSL. Writing a BER decoder just for Bitcoin is a bad idea, it is much more likely our new code would have a crashing bug.
legendary
Activity: 1072
Merit: 1181
August 22, 2012, 09:21:31 AM
#17
I'm re-investigating this past problem because I think there are some other possibilities for this attack vector.

Did Sipa implemented a patch back on MAY 2011 to check the uniqueness and correctness of signatures?

I don't see a IsValidSig() method in the source code.

Bet regards, Sergio.

No, this was never fixed. Doing it now would at first making transactions which use non-standard but valid encodings non-standard, and then fixing a policy for a transition point after which it becomes illegal.
hero member
Activity: 555
Merit: 654
August 22, 2012, 08:46:33 AM
#16
I'm re-investigating this past problem because I think there are some other possibilities for this attack vector.

Did Sipa implemented a patch back on MAY 2011 to check the uniqueness and correctness of signatures?

I don't see a IsValidSig() method in the source code.

Bet regards, Sergio.
full member
Activity: 327
Merit: 124
May 18, 2011, 11:30:49 AM
#15
I don't like the idea of openssl segfaulting on garbage data.

Is there an easy way for checking (by looking at the bytes ourselves, not by passing it to openssl and request to encode it again) that the input is a valid DER-encoded signature?


Well, you know a valid bitcoin signature (r,s) is going to look like

<30><02><02><01>

where the r and s values are non-negative, and don't exceed 33 bytes including a possible padding zero byte.

One way to check would be to just create a little function

bool IsValidSig(char *sig, int siglen)

Containing an appropriate stack of if statements.

Pages:
Jump to:
© 2020, Bitcointalksearch.org