Design Patterns which Facilitate Message Digest Collision ... · Design Patterns to Avoid /...

Copyright © 2017 Peter Robinson

Design Patterns which Facilitate Message Digest Collision Attacks on BlockchainsPeter Robinson, [email protected] of Information Technology and Electrical Engineering, University of Queensland.

Symposium on Distributed Ledger Technology SDLT'2017Gold Coast Campus, Griffith UniversityJune 13, 2017


Overview

▪ Message digest algorithms are one of the underlying building blocks of blockchainplatforms such as Ethereum.

▪ This paper analyses situations in which the message digest collision resistance property can be exploited by attackers.

▪ Two mitigations for possible attacks are described: ▪ Longer message digest sizes make attacks more difficult; and,

▪ Including timeliness properties limits the amount of time an attacker has to determine a hash collision.

2Ref 1: Image on cover slide: Preneel, B. (2013) “Introduction to the Design and Cryptanalysis of Cryptographic Hash Functions”Available: https://www.cosic.esat.kuleuven.be/summer_school_albena/slides/preneel_hash_july2013_shortv1_print.pdf


Message Digest / Cryptographic Hash Algorithms

▪ Digest Algorithm (Hash):▪ Variable length input => Fixed Length Output.

▪ Address Hash: ▪ Bitcoin and Ripple: RIPEMD160(SHA256): 160 bit digest,

▪ Ethereum: KECCAK/160: 160 bit digest.

▪ Main Hash: ▪ Bitcoin: SHA256(SHA256): 256 bit digest,

▪ Ethereum: KECCAK/256: 256 bit digest,

▪ Ripple: 256 bit truncated SHA512: 256 bit digest.

3


Message Digest Security Strength & Cryptanalysis

4

?

Preimage Resistance

Hash

nn/2

h(x)

x

Second Preimage Resistance

Hash

h(x)

?

Hash

h(x’)

≠

=

?

CollisionResistance

Hash

h(x)

?

Hash

h(x’)

≠

=n

n/2n/2n/3

ClassicalQuantum


NIST Recommendation on Security Strength

▪ 80 bit Security Strength algorithms should not be used after 20102.

▪ 160 bit message digest functions provide 80 bits of security strength for collision resistance property.

▪ Address hashes used by Bitcoin, Ethereum, and Ripple may be susceptible to collision attacks by large state based actors.

5

Ref 2: NIST (2009) “DISCUSSION PAPER: The Transitioning of Cryptographic Algorithms and Key Sizes”http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdfSP800-57: http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdfEINSA: https://www.enisa.europa.eu/publications/algorithms-key-sizes-and.../fullReport


Design Patterns to Avoid / Exploitation Scenarios

▪ The attacker chooses the value to be digested.

▪ The attacker is able to trick an entity into doing something based the message digest and value.

▪ There is no time-sensitive aspect to the value.▪ Time-sensitivity is important as the first message digest collisions for an algorithm have

historically taken a significant period of time.

6


Attack Scenario #1: EIP86Transaction Verification Contracts

▪ Contract is deployed the address calculated as:

Keccak256(rlp:encode([creator+nonce+initcode]))%2160

▪ Where:▪ creator is the account that created the contract,

▪ nonce is a value which should be sequential,

▪ initcode is the initialization code for the contract.

7


Attack Scenario #1: EIP86Transaction Verification Contracts

▪ An attacker who had broken the message digest collision resistance property could manipulate the nonce value or the contents of the contract such that there exists two contracts which would be deployed to the same address.

▪ The attacker could show one variant of the contract to a user and persuade them to send some Ether to the address. The attacker could then deploy the nefarious contract and spend the Ether.

8


Attack Scenario #2: Proposal forProof of Stake Agreed Random Number

▪ Ethereum’s Proof of Stake proposal needs an agreed random number to use to choose which miner will create the next block.

▪ One proposal is:▪ Each miner generates a random value,

▪ To prevent cheating, miners submit commitment values: message digest(random value),

▪ The random values are then exposed and combined using XOR to produce the agreed random number.

9


Attack Scenario #2: Proposal forProof of Stake Agreed Random Number

▪ An attacker who had broken the collision resistance property could:▪ Determine two random values which hash to produce the same commitment value,

▪ Submit their commitment value,

▪ Then, after seeing the random values exposed by the other miners, choose which of their random values to deliver, thus influencing the resulting agreed random number.

10


Design Pattern & Attack Mitigations

▪ The message digest size used for account numbers should be increased. ▪ In an email from V. Buterin and M. Swende from the Ethereum team on May 18, 2017,

they tentatively agreed to adopt this recommendation of mine.

▪ A temporal component should be incorporated into designs. ▪ The random value proposed for use in PoS should incorporate some value from a recent

block.

11


Questions

12

Design Patterns which Facilitate Message Digest Collision ... · Design Patterns to Avoid /...

Documents

Transcript of Design Patterns which Facilitate Message Digest Collision ... · Design Patterns to Avoid /...