<p>The solution is the same regardless of curve or signature algorithm -- reject non-canonical signatures. This is precisely what Bitcoin has decided to do.</p>

CC BY-SA 3.0
2014-02-12T00:31:14.863Z
This answer doesn't apply to my question.  Is there a signature format, or encryption type that makes it impossible to have multiple values for a signature.  Can you help me rephrase...?
makerofthings7
CC BY-SA 3.0
2014-02-12T01:29:38.077Z
I think the answer is "yes, a canonical signature format makes it impossible to have multiple values for a signature". The software just needs to reject non-canonical signatures.
Greg Hewgill
CC BY-SA 3.0
2014-02-12T04:59:55.037Z
@makerofthings7 Any scheme, provided non-canonical signatures are rejected.
David Schwartz
CC BY-SA 3.0
2014-02-12T05:03:39.500Z
understood, but I'm looking at cryptocurrencies in general, not specific to Bitcoin, that may allow or promote signature schemes that don't require the implementation detail of ensuring canonical signatures.  (hence the comment "even Mt Gox would get it right).  What crypto approach would eliminate this need (outside of Bitcoin and QT reference client)
makerofthings7
CC BY-SA 3.0
2014-02-12T05:37:22.290Z
@makerofthings7 If you reject non-canonical signatures, then there is no problem. There's one and only one "right" form of each signature. If you don't, then there will always be this problem. Someone can replace a canonical signature with a non-canonical one. Note that there's nothing special Mt Gox (or users in general) have to do. The currency's transaction processing engine has to reject non-canonical signatures. The reason users and issuers had to do special things is that Bitcoin *didn't* reject non-canonical signatures.
David Schwartz
CC BY-SA 3.0
2014-02-12T06:22:17.533Z
My question phrased a different way... Do all crypto signatures ... Not just the ones in Bitcoin (RSA for example... El gamal... Etc) have the ability for a signature to be represented in many ways?
makerofthings7
CC BY-SA 3.0
2014-02-12T06:49:29.687Z
That has nothing to do with the algorithm, that has to do with how you choose to represent the signatures. For example, say a signature algorithm produced a signature of seventeen. Regardless of the algorithm if you treat "017" as equivalent to "17", then you have more than one way to represent the signature. It has nothing to do with the crypto algorithm but with the rules you use for validating the representations of signatures. If the representation validity rules provide one and only one way to represent any given signature, you are good. If not, not.
David Schwartz
CC BY-SA 3.0
2014-02-11T23:50:56.627Z
2014-02-11T23:50:56.627Z
David Schwartz
<p>EDIT: This question is not specific to Bitcoin.  It's applicable to any other crypto currency that is interested in using a different signature scheme than Bitcoin or the QT reference client.  One reason for this is to reduce complexity (and bugs) in the protocol.</p>

<p>My understanding of malleable transactions in Bitcoin is that two different values are supported for "S" when a signature is validated.</p>

<p>The solution for this is to ensure that S is less than the following</p>

<pre><code>  X9ECParameters ecParams = Org.BouncyCastle.Asn1.Sec.SecNamedCurves.GetByName("secp256k1");

  HALF_CURVE_ORDER = ecParams.N.ShiftRight(1);
</code></pre>

<p>Given the plethora of signature mechanisms available to crypto-currency, what algorithms or signature approaches are not vulnerable to Malleable Transactions?</p>

<p>e.g.  What if...</p>

<ul>
<li>A different curve was selected instead of secp256k1?</li>
<li>A different signature mechanism was chosen? </li>
<li>A different approach entirely, such as a blind HMAC was used to sign transactions?</li>
</ul>

<p>I'm interested in answers that describe both solutions that are broken, and those that would prevent malleable transactions from ever occurring.</p>

<p>My goal is to flush out an algorithm that produces consistent results with minimal complexity for implementors.  (in other words, even Mt Gox would get it right)</p>

CC BY-SA 3.0
2014-02-11T23:56:37.970Z
possible duplicate of [Is this "transaction malleability" really an issue?](http://bitcoin.stackexchange.com/questions/21959/is-this-transaction-malleability-really-an-issue)
John T
CC BY-SA 3.0
2014-02-12T00:32:51.887Z
@JacobTorba Not a duplicate, I'm asking if a signature format exists that doesn't have this issue.  I'm aware of all the answers of that question, and none relate.  Perhaps you can help me clarify?
makerofthings7
CC BY-SA 3.0
2014-02-12T00:35:39.513Z
you're right! This is a legitimate question with a tricky title, my bad.
John T
CC BY-SA 3.0
2014-02-12T00:38:02.020Z
I think you are having trouble with the way hashing works, it's not so that sha256 hashing causes the multiple values, it's all about what is fed into the hash function. Could you be talking about avoiding [collisions?](http://en.wikipedia.org/wiki/Collision_(computer_science)) Theres an extremely small chance for those.
John T
CC BY-SA 3.0
2014-02-12T00:57:19.653Z
My focus is specifically on two public keys that can generate the same signature.  The change in signature results in a different sha256 hash (of course).  I'm focused primarily on the S value of the signature being less than half of the curve order as defined by this e.g. `HALF_CURVE_ORDER = ecParams.N.ShiftRight(1);`
makerofthings7
<development><cryptography><signature><risk-mitigation><transaction-malleability>
Is there a signature format, or cryptography has *only one* possible S value?
makerofthings7
# Is there a signature format, or cryptography has *only one* possible S value?

(Asked by: username_0 on 2014-02-11)

EDIT: This question is not specific to Bitcoin. It's applicable to any other crypto currency that is interested in using a different signature scheme than Bitcoin or the QT reference client. One reason for this is to reduce complexity (and bugs) in the protocol.

My understanding of malleable transactions in Bitcoin is that two different values are supported for "S" when a signature is validated.

The solution for this is to ensure that S is less than the following

```
  X9ECParameters ecParams = Org.BouncyCastle.Asn1.Sec.SecNamedCurves.GetByName("secp256k1");

  HALF_CURVE_ORDER = ecParams.N.ShiftRight(1);

```

Given the plethora of signature mechanisms available to crypto-currency, what algorithms or signature approaches are not vulnerable to Malleable Transactions?

e.g. What if...

* A different curve was selected instead of secp256k1?
* A different signature mechanism was chosen?
* A different approach entirely, such as a blind HMAC was used to sign transactions?

I'm interested in answers that describe both solutions that are broken, and those that would prevent malleable transactions from ever occurring.

My goal is to flush out an algorithm that produces consistent results with minimal complexity for implementors. (in other words, even Mt Gox would get it right)

**Tags:** development, cryptography, signature, risk-mitigation, transaction-malleability

> **Comments:**
> **username_1**: possible duplicate of [Is this "transaction malleability" really an issue?](http://bitcoin.stackexchange.com/questions/21959/is-this-transaction-malleability-really-an-issue)  
> **username_0**: @JacobTorba Not a duplicate, I'm asking if a signature format exists that doesn't have this issue.  I'm aware of all the answers of that question, and none relate.  Perhaps you can help me clarify?  
> **username_1**: you're right! This is a legitimate question with a tricky title, my bad.  
> **username_1**: I think you are having trouble with the way hashing works, it's not so that sha256 hashing causes the multiple values, it's all about what is fed into the hash function. Could you be talking about avoiding [collisions?](http://en.wikipedia.org/wiki/Collision_(computer_science)) Theres an extremely small chance for those.  
> **username_0**: My focus is specifically on two public keys that can generate the same signature.  The change in signature results in a different sha256 hash (of course).  I'm focused primarily on the S value of the signature being less than half of the curve order as defined by this e.g. `HALF_CURVE_ORDER = ecParams.N.ShiftRight(1);`  

---

## 1 answers

### Answer by username_2 on 2014-02-11. Score: 1

The solution is the same regardless of curve or signature algorithm -- reject non-canonical signatures. This is precisely what Bitcoin has decided to do.

> **Comments:**
> **username_0**: This answer doesn't apply to my question.  Is there a signature format, or encryption type that makes it impossible to have multiple values for a signature.  Can you help me rephrase...?  
> **username_3**: I think the answer is "yes, a canonical signature format makes it impossible to have multiple values for a signature". The software just needs to reject non-canonical signatures.  
> **username_2**: @username_0 Any scheme, provided non-canonical signatures are rejected.  
> **username_0**: understood, but I'm looking at cryptocurrencies in general, not specific to Bitcoin, that may allow or promote signature schemes that don't require the implementation detail of ensuring canonical signatures.  (hence the comment "even Mt Gox would get it right).  What crypto approach would eliminate this need (outside of Bitcoin and QT reference client)  
> **username_2**: @username_0 If you reject non-canonical signatures, then there is no problem. There's one and only one "right" form of each signature. If you don't, then there will always be this problem. Someone can replace a canonical signature with a non-canonical one. Note that there's nothing special Mt Gox (or users in general) have to do. The currency's transaction processing engine has to reject non-canonical signatures. The reason users and issuers had to do special things is that Bitcoin *didn't* reject non-canonical signatures.  
> **username_0**: My question phrased a different way... Do all crypto signatures ... Not just the ones in Bitcoin (RSA for example... El gamal... Etc) have the ability for a signature to be represented in many ways?  
> **username_2**: That has nothing to do with the algorithm, that has to do with how you choose to represent the signatures. For example, say a signature algorithm produced a signature of seventeen. Regardless of the algorithm if you treat "017" as equivalent to "17", then you have more than one way to represent the signature. It has nothing to do with the crypto algorithm but with the rules you use for validating the representations of signatures. If the representation validity rules provide one and only one way to represent any given signature, you are good. If not, not.  

---

