Jump to content
T8493

Signing the same transactions with different secret number k

Recommended Posts

I'm having some issues with failed transactions.

One of the issues was related to the fact that the second transaction was signed using the same private key but with a different temporal key (secret number) k. I'm not using RFC6979.

Are there any potential pitfalls if I submit the same transaction signed with a different secret number k?

 

 

Edited by T8493

Share this post


Link to post
Share on other sites
1 hour ago, nikb said:

You'll have to be more specific: what issues are you having?

Thanks for your answer. I have issues with my software.

In the document "Reliable transaction submission" there is a step "Repeat submission of original transaction".

https://ripple.com/build/reliable-transaction-submission/#verification

Can I (re)submit the same transaction signed with different value k here?

I don't have any hard numbers but somehow it doesn't look like resubmitting the transaction (signed with different k) increases the chance of this transaction being included in a validated ledger. But maybe this is an entirely unrelated issue.

Edited by T8493

Share this post


Link to post
Share on other sites
12 minutes ago, tulo said:

What's the secret number k? I'm curious because I've never heard it...

ECDSA signing algorithm generates secret number k and uses it during the calculation of the digital signature.

Take a look at step 3 of the signing algorithm here:

https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm

Secret number can be:

  • generated randomly for each signature (using the cryptographically secure random number generator) 
  • generated deterministically (using the algorithm described in RFC6979)

This number is extremely important (if it is not generated properly this fact can be used to completely break ECDSA).

 

Edited by T8493

Share this post


Link to post
Share on other sites
4 hours ago, nikb said:

You still haven't explained what the problem that  you're facing is. Do you get an error code from rippled when you aren't expecting one?

I had a longer answer but the editor deleted the content of my post.... So here is the shortened version.

There is not necessarily any issue with rippled. I just wanted to rule out the possibility that signing with different k automatically triggers some specific behavior.

The main "observation" is that the second transaction (signed with different k) is almost never applied to a validated ledger. And so resubmitting a transaction is almost always pointless. I don't have any hard numbers to back up this claim and there are a lot of other possible reasons for this.

 

Submitting the same transaction but signed with different k *might* (at least in theory) be used to influence transaction ordering in the validated ledger (order is deterministic). Something like this 

http://availableimagination.com/exploiting-ripple-transaction-ordering-for-fun-and-profit/

except that in my case attacker is changing value k. This would allow front running. And rippled could have some mechanisms in place which would prevent or at least discourage this behavior (for example, it would silently drop second transaction (signed with different k)).

 

 

 

Edited by T8493

Share this post


Link to post
Share on other sites
11 hours ago, T8493 said:

In the document "Reliable transaction submission" there is a step "Repeat submission of original transaction".

https://ripple.com/build/reliable-transaction-submission/#verification

Can I (re)submit the same transaction signed with different value k here?

 
 

Ok, this was stupid and unrelated question, please ignore it (in this case resubmitted transaction must have different LastLedgerSequence and it is therefore not "the same")

Edited by T8493

Share this post


Link to post
Share on other sites
3 hours ago, T8493 said:

Submitting the same transaction but signed with different k *might* (at least in theory) be used to influence transaction ordering in the validated ledger (order is deterministic). Something like this 

http://availableimagination.com/exploiting-ripple-transaction-ordering-for-fun-and-profit/

except that in my case attacker is changing value k. This would allow front running. And rippled could have some mechanisms in place which would prevent or at least discourage this behavior (for example, it would silently drop second transaction (signed with different k)).

This was changed, so the order is  should now be non-deterministic. For frontrunning I think now it is sufficient to spam lots of transactions with high fee, such that the other transactions are queued and your is executed before.

Share this post


Link to post
Share on other sites
2 hours ago, tulo said:

This was changed, so the order is  should now be non-deterministic. For frontrunning I think now it is sufficient to spam lots of transactions with high fee, such that the other transactions are queued and your is executed before.

 
 
 

 

Transaction ordering is still deterministic (but it is practically impossible to "guess" the order AFAIK). Signing transactions with different values k could help with spamming because you don't have to change the content of the transaction (content of the transaction stays the same, just the signature is different).

 

Edited by T8493

Share this post


Link to post
Share on other sites

T8493 is correct -- transaction ordering is still deterministic (it has to be!) but is now harder to game. Basically the rule for how transactions from different addresses are ordered is now dependent on the contents or hash of the ledger itself (I don't remember exactly what) instead of being mostly based on alphabetizing the transaction hashes.

Regarding signing with a different k, my understanding is that rippled does not pay any specific attention to that. It only checks that the signature is valid for the transaction fields. However, I think the identifying hash is calculated for the transaction including the signature so it's not considered the exact same transaction unless the signature is identical. If you change the signature, the resubmitted version is "competing" with the first submission to be included in a ledger because they have the same sequence number. That's probably fine because the main reason you'd resubmit a transaction without changing anything else is that it just didn't get distributed to enough servers because of some sort of temporary condition (e.g. your connection dropped while you were sharing it with the first rippled).

If you're changing anything else about the transaction, like its LastLedgerSequence (because enough time passed between the initial submission and the resubmit that the old LastLedgerSequence has already passed or is about to) then it's basically a new transaction in that case also.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×