You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Despite being mostly fixed in 2014, transaction malleability is still theoretically a problem today, because you have to opt in to protection from it by setting tfFullyCanonicalSig. We can fix this with an amendment that makes non-fully-canonical signatures invalid regardless of transaction flags.
Background
The tfFullyCanonicalSig flag was created to allow backwards compatibility with transactions signed with old signing logic that didn't create fully-canonical signatures. This design leaves all transactions valid, but makes full protection from transaction malleability (sort-of) opt-in.
As far as I know, every tool in use today generates fully-canonical signatures, but malicious actors could still convert transactions to non-fully-canonical signatures, resulting in a different hash, if those transactions don't have tfFullyCanonicalSig enabled. This could be used to trick naive transaction submission logic into sending the same payment multiple times.
By default, rippled's sign method supplies a Flags field with tfFullyCanonicalSig enabled if you don't provide a Flags field. However, tfFullyCanonicalSig won't be enabled in the following cases:
If you use ripple-lib's signing functionality without "preparing" the transaction first (see also: ripple-lib PR#1028)
If you multi-sign using rippled's sign_for method and didn't explicitly set the tfFullyCanonicalFlag
If you use rippled's sign method but explicitly supply a Flags field that doesn't include tfFullyCanonicalSig—for example, if you're using another flag, and you don't bitwise-OR it with the tfFullyCanonicalSig value.
If you're using your own signing logic that doesn't supply tfFullyCanonicalSig.
This state of affairs requires users to take extra steps to protect themselves against transaction malleability in some cases, and leaves many transactions vulnerable because users forgot or misunderstood the necessary steps.
Proposed Solution
Create an amendment named RequireFullyCanonicalSig (or something along those lines). With this amendment enabled, non-fully-canonical transaction signatures are always considered invalid regardless of whether tfFullyCanonicalSig is specified. (Basically, transactions are treated like tfFullyCanonicalSig is enabled even if it isn't.)
Compatibility with Legacy Transactions
If there are any tools today that create non-fully-canonical signatures by default, those tools break. Both rippled (v0.24.0?) and ripple-lib (v0.9.0?) have created only fully-canonical signatures since 2014. I'm not familiar with any tools that do not create fully-canonical signatures.
Any transactions that were signed in a non-fully-canonical way are no longer valid and cannot be successfully submitted as-is. These could be transactions that were signed in or before early 2014 and put "in cold storage" indefinitely without being submitted. It is not clear if there are any such transactions in existence or how many such transactions would still be valid under current transaction processing rules because of other breaking changes.
If necessary, we could publish a tool that can convert non-fully-canonical signatures to fully-canonical signatures. Basically, this tool would take advantage of the malleability of those transactions to make fully-canonical variants of them without needing anything beyond the signed blob of the transaction itself. This would of course result in a slightly different blob and a different hash, but anyone who has such transactions in cold storage could use this tool to convert them to fully-canonical signatures.
It would probably be advisable not to publish the tool before the amendment became enabled, since it basically would provide sample code for several steps of the existing exploit against transactions not using tfFullyCanonicalSig.
However, it remains to be seen whether such a tool is necessary at all since the existence of any such cold-storage non-fully-canonical transactions is hypothetical.
The text was updated successfully, but these errors were encountered:
Summary
Despite being mostly fixed in 2014, transaction malleability is still theoretically a problem today, because you have to opt in to protection from it by setting tfFullyCanonicalSig. We can fix this with an amendment that makes non-fully-canonical signatures invalid regardless of transaction flags.
Background
The tfFullyCanonicalSig flag was created to allow backwards compatibility with transactions signed with old signing logic that didn't create fully-canonical signatures. This design leaves all transactions valid, but makes full protection from transaction malleability (sort-of) opt-in.
As far as I know, every tool in use today generates fully-canonical signatures, but malicious actors could still convert transactions to non-fully-canonical signatures, resulting in a different hash, if those transactions don't have tfFullyCanonicalSig enabled. This could be used to trick naive transaction submission logic into sending the same payment multiple times.
By default,
rippled
'ssign
method supplies aFlags
field with tfFullyCanonicalSig enabled if you don't provide aFlags
field. However, tfFullyCanonicalSig won't be enabled in the following cases:rippled
'ssign_for
method and didn't explicitly set the tfFullyCanonicalFlagrippled
'ssign
method but explicitly supply aFlags
field that doesn't include tfFullyCanonicalSig—for example, if you're using another flag, and you don't bitwise-OR it with the tfFullyCanonicalSig value.This state of affairs requires users to take extra steps to protect themselves against transaction malleability in some cases, and leaves many transactions vulnerable because users forgot or misunderstood the necessary steps.
Proposed Solution
Create an amendment named RequireFullyCanonicalSig (or something along those lines). With this amendment enabled, non-fully-canonical transaction signatures are always considered invalid regardless of whether tfFullyCanonicalSig is specified. (Basically, transactions are treated like tfFullyCanonicalSig is enabled even if it isn't.)
Compatibility with Legacy Transactions
If there are any tools today that create non-fully-canonical signatures by default, those tools break. Both rippled (v0.24.0?) and ripple-lib (v0.9.0?) have created only fully-canonical signatures since 2014. I'm not familiar with any tools that do not create fully-canonical signatures.
Any transactions that were signed in a non-fully-canonical way are no longer valid and cannot be successfully submitted as-is. These could be transactions that were signed in or before early 2014 and put "in cold storage" indefinitely without being submitted. It is not clear if there are any such transactions in existence or how many such transactions would still be valid under current transaction processing rules because of other breaking changes.
If necessary, we could publish a tool that can convert non-fully-canonical signatures to fully-canonical signatures. Basically, this tool would take advantage of the malleability of those transactions to make fully-canonical variants of them without needing anything beyond the signed blob of the transaction itself. This would of course result in a slightly different blob and a different hash, but anyone who has such transactions in cold storage could use this tool to convert them to fully-canonical signatures.
It would probably be advisable not to publish the tool before the amendment became enabled, since it basically would provide sample code for several steps of the existing exploit against transactions not using tfFullyCanonicalSig.
However, it remains to be seen whether such a tool is necessary at all since the existence of any such cold-storage non-fully-canonical transactions is hypothetical.
The text was updated successfully, but these errors were encountered: