We have run the ecc library we are using over the bitcoind test vectors, everything passes.
Cheers. I will now decline to pay your tantrum further attention. If you have any additional bug reports of a security nature, we now both know that you know both the professional as well as the attention-seeking routes to report them.
Hi, so what is the purpose of all the complexity? Is it optimization? Because it looks like alien-speak to me. And I know it, I'm an idiot. Thing is just about everyone is.
So complexity like this is going to harm this site and its community in the long run.
Please be encouraged to test our software in the same manner and report in the same manner as strident and loud as you'd like. We'd rather that than have security issues effect our users. Really, you're encouraged.
Further, we'd love to talk with you about safely interoperating. There's a lot of room to grow guys. I mean, a lot. So shall we grow?
Odd that my account on your slack got deleted after I posted about interoperating. That was my last post of course, but I can't know why it was deleted. Maybe it's because I'd mention something like this. Maybe it's because I'd like my software to work with yours. Maybe it's because you folks are gun-shy and paranoid. Maybe it's because I'm too loud and push too hard.
I am glad u brought this to the blockchain though i will "speculate" that given what ive seen it does look like the cryptography has been tampered with or is at least different from what it seems it should be.
Trouble with stuff like this is that it's really hard to pin down what may be the cause. It does not seem like they are using the canonical secp256k1. @baabeetaa and I are happy to speak with anyone about exactly how we ended up finding it. @baabeetaa suggests creating RPC libraries.
Well i will be actively trying to help you all get to the bottom of this. I really do remember bytemaster (aka dan larimer) saying graphene using deterministic signature scheme...but that was awhile ago and was before Steem existed. So i might be completely wrong.
Im just thankful that it wasnt something worse than this. I was a bit concerned what this could mean...
Thank you fuzzy. My total assessment is that I don't know. Thing is I or anyone should be able to know. Hell, you should be able to know, even as you say as a "code-idiot".
I wouldnt calt it tampering but simply being more strict. That is evetything there is to see. Graphene simply doesnt accept every signature that is valid for other chains but requires additional properties to be fulfilled. Namely r and s need to be of lenght 32. No way around it and the only possible way to achieve such a property for any message is to pick a deterministic k and add a random part to it and try with another sig.
Tale a look at how canonicality is done in ethereum. You will be surprised.
Thinking about how to approach this to see if I am FUD-ing or not, I'm installing Parity, the leading ethereum client, and I'll compare to the same steps on graphene.
If your serialization expects a 65byte signature and you only provide 63 byte .. then it needs to either perform running length encoding or do zero padding. The former leads to additional data on the serialization while the latter leaves you with meaningless bytes in the serialization that can be used to hide information (e.g. leakage of private key data) -- this is particularilly a concern for hardware wallets where you don't see what code is actually executed.
That said, restricting signatures to 65bytes is easiest with respect to security, scalability and network efficiency.
You are actually right, the canonicality of eth signatures does not require a loop, but they need to deal with signatures that are (maybe) shorter than 64bytes. How they deal with it is their decision to make. Graphene architects made the decision to not allow shorter signatures and there are good reasons to do so: backend performance, information leakage, consistency, etc..
Have I ever had anything to send there before?
Did I have a communications channel that got cut off?
Why should I be aware of this?
Aren't you happy I reported it instead of not?
Let's get down to brass tacks: who did your secp256k1 code for C++ and JavaScript?
Do you claim to be using canonical SECP256k1?
How about the non determinism?
For your information Steem.js is using
ecurvepackage to implement secp256k1 see here: https://github.com/steemit/steem-js/blob/8c6fdd26311353aedaed47abb5ad5880e7a8e0d1/src/auth/ecc/src/key_public.js#L3The same implantation is been used on the official BitCoin JS library: https://github.com/bitcoinjs/bitcoinjs-lib/blob/14f9218389a80f3eed177f43113b3a437944f7f9/test/integration/crypto.js#L10
We should be safe.
LOL FABIEN SERIEUX
We have run the ecc library we are using over the bitcoind test vectors, everything passes.
Cheers. I will now decline to pay your tantrum further attention. If you have any additional bug reports of a security nature, we now both know that you know both the professional as well as the attention-seeking routes to report them.
Good day.
Hi, so what is the purpose of all the complexity? Is it optimization? Because it looks like alien-speak to me. And I know it, I'm an idiot. Thing is just about everyone is.
So complexity like this is going to harm this site and its community in the long run.
Please be encouraged to test our software in the same manner and report in the same manner as strident and loud as you'd like. We'd rather that than have security issues effect our users. Really, you're encouraged.
Further, we'd love to talk with you about safely interoperating. There's a lot of room to grow guys. I mean, a lot. So shall we grow?
Odd that my account on your slack got deleted after I posted about interoperating. That was my last post of course, but I can't know why it was deleted. Maybe it's because I'd mention something like this. Maybe it's because I'd like my software to work with yours. Maybe it's because you folks are gun-shy and paranoid. Maybe it's because I'm too loud and push too hard.
That's the trouble, as always: I can't know.
Hope the next time someone hits something that looks like a security problem, they report it, too. Your approach won't help much.
Generally they do, as it says right in our readme how to email us. You are the first and only one thus far to take the public tantrum approach.
Damn. I am such an asshole.
I am glad u brought this to the blockchain though i will "speculate" that given what ive seen it does look like the cryptography has been tampered with or is at least different from what it seems it should be.
Trouble with stuff like this is that it's really hard to pin down what may be the cause. It does not seem like they are using the canonical secp256k1. @baabeetaa and I are happy to speak with anyone about exactly how we ended up finding it. @baabeetaa suggests creating RPC libraries.
Well i will be actively trying to help you all get to the bottom of this. I really do remember bytemaster (aka dan larimer) saying graphene using deterministic signature scheme...but that was awhile ago and was before Steem existed. So i might be completely wrong.
Im just thankful that it wasnt something worse than this. I was a bit concerned what this could mean...
Thank you fuzzy. My total assessment is that I don't know. Thing is I or anyone should be able to know. Hell, you should be able to know, even as you say as a "code-idiot".
I wouldnt calt it tampering but simply being more strict. That is evetything there is to see. Graphene simply doesnt accept every signature that is valid for other chains but requires additional properties to be fulfilled. Namely r and s need to be of lenght 32. No way around it and the only possible way to achieve such a property for any message is to pick a deterministic k and add a random part to it and try with another sig.
Tale a look at how canonicality is done in ethereum. You will be surprised.
@xeroc,
Looking.
This? And the few other related bits across their code?
https://github.com/ethereum/go-ethereum/blob/6d15d00ac4b5f162737a27dfa6f8e9976383776e/accounts/abi/event.go
Yes, it looks a good deal simpler.
Or this?
https://github.com/ethcore/parity/blob/8404edb656693270ec1cd3956d204f625d28ec7c/ethcore/src/verification/canon_verifier.rs
They both look much simpler to me.
@xeroc
Thinking about how to approach this to see if I am FUD-ing or not, I'm installing Parity, the leading ethereum client, and I'll compare to the same steps on graphene.
If your serialization expects a 65byte signature and you only provide 63 byte .. then it needs to either perform running length encoding or do zero padding. The former leads to additional data on the serialization while the latter leaves you with meaningless bytes in the serialization that can be used to hide information (e.g. leakage of private key data) -- this is particularilly a concern for hardware wallets where you don't see what code is actually executed.
That said, restricting signatures to 65bytes is easiest with respect to security, scalability and network efficiency.
You are actually right, the canonicality of eth signatures does not require a loop, but they need to deal with signatures that are (maybe) shorter than 64bytes. How they deal with it is their decision to make. Graphene architects made the decision to not allow shorter signatures and there are good reasons to do so: backend performance, information leakage, consistency, etc..
How is it possible to optimize for back-end performance without potentially leaking information?
Also, doesn't a variable key length improve the situation overall and reflect a more standard implementation?