You are viewing a single comment's thread from:
RE: Why does steem use this canonical thing instead of strict secp256k1?
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?