36

During the launch of the frontier network, users were cautioned not to reuse keys from the Olympic testnet in order to prevent "replay attacks". What is a replay attack, and why would re-using a key from the testnet make someone vulnerable to one?

q9f
  • 32,913
  • 47
  • 156
  • 395
Jeff Coleman
  • 22,059
  • 17
  • 77
  • 91

3 Answers3

25

A replay attack is a valid data transmission that is maliciously or fraudulently repeated or delayed.

Extending this to blockchains, a replay attack is taking a transaction on one blockchain, and maliciously or fraudulently repeating it on another blockchain.

For example, an attacker taking someone's testnet transaction, and repeating it on the "real" blockchain, to steal "real" funds.

As @libertylocked commented, EIP 155 Simple replay attack protection has been implemented.

More Info

In Bitcoin, addresses in testnet use a different prefix from addresses in mainnet: thus keys are different.

In Ethereum, there are currently no "prefixes". (Probably done to keep creation of new addresses simpler.) So a transaction signed by a key, that is valid on one Ethereum network/chain, is valid for all Ethereum chains.

This means that if in "testing", funds are sent from accountB to accountTest, that same transaction can be replayed (broadcasted) to the public Ethereum blockchain: a replay attack. The replay attack will "succeed" if accountB does have funds on the public blockchain. To fully succeed, an attacker would need to know the private key to accountTest to steal the funds, but given that accountTest was created for testing, its private key may not be secure (maybe it is just a "brainwallet" with password "test").

Replay attacks are eliminated by using different addresses/keys between the frontier network, and all other Ethereum chains. (A little like using a different password for valuable stuff, from less valuable or less trustworthy websites.) Also see: How to prevent a replay attack between two competing chains? and as noted by @libertylocked comment, EIP 155 Simple replay attack protection has been implemented.

eth
  • 85,679
  • 53
  • 285
  • 406
  • 1
    And to confirm.. In creating 'new' accounts on each chain, whilst these creations can also be replayed doing so would be pointless because you still control the private key to said account(s). Is that correct understanding? – Thomas Clowes Jul 24 '16 at 21:22
  • As I understand, the double broadcast on the unintended chain reuses the already signed transaction data, so no private key is needed for the attack. It's a kind of "man-in-the-middle" attack, compromising the data flow of a supposedly secured channel. – Sz. Jul 28 '17 at 14:17
  • @ThomasClowes Correct, it would be pointless because you still control the private key to said account(s). – eth Aug 10 '17 at 06:12
  • @Sz You're correct about the "general" case. If you are responding to Thomas's comment, then you replaying a transaction that sends funds to Thomas's private key isn't an "attack" since the funds are still controlled by Thomas. It certainly would be different if Thomas sent you funds on one chain, and then in that case you could certainly replay it to get Thomas's funds on the other chain and that would be an attack. – eth Aug 10 '17 at 06:16
  • 1
    EIP155 introduced CHAIN_ID as part of the recovery byte when verifying transaction signature. Therefore transactions sent on one network will not have the correct signature on another chain ID – libertylocked Sep 30 '18 at 01:45
14

It means that a transaction that was valid on the Olympic testnet was still valid for next release (Frontier).

If you made a transaction T in Olympic that sends Ether from address A to B, and then reuse the key behind address A in the Frontier release, that transaction T could be broadcasted again (replayed) and the transfer from A to B would happen in Frontier, even if you (owner of A) didn't intend to do it.

That's why people were asked not to reuse keys.

arhuaco
  • 241
  • 1
  • 6
5

To avoid replay attack use EIP155 transaction types which are available since block 2675000. They incorporate chainID to the transaction signature. Make sure your wallet software is EIP155 enabled and you will be safe

Mike Shultz
  • 1,212
  • 11
  • 20
Nulik
  • 4,061
  • 1
  • 18
  • 30