From 569046321b9915cbd6acb71502b229390848afa0 Mon Sep 17 00:00:00 2001 From: Benjamin Loison Date: Mon, 5 Jun 2023 17:19:49 +0200 Subject: [PATCH] Solve potential length extension attack by using SHA-3 --- common.py | 5 ++--- meta.py | 3 --- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/common.py b/common.py index 8d04853..3071552 100644 --- a/common.py +++ b/common.py @@ -1,5 +1,5 @@ import math -from hashlib import sha256 +from hashlib import sha3_256 SECURITY_PARAMETER = 256 # Note that notably `MAXIMUM_HASH_DIFFICULTY` and `SPACE_TO_PROVE_IN_BITS` should be sent from the prover to the verifier before the second verifier initialization step. However to ease this prototype this communication isn't performed. @@ -29,9 +29,8 @@ ENTRIES_NUMBER = math.ceil(SPACE_TO_PROVE_IN_BITS / NUMBER_OF_BITS_IN_AVERAGE_FO ENTRIES_NUMBER = 2 ** math.ceil(math.log2(ENTRIES_NUMBER)) LEVELS = int(math.log2(ENTRIES_NUMBER)) + 1 -# Do we have a problem due to length extension attacks? If so, could sha256 one more time as in Bitcoin. def hash(x): - return sha256(x.encode('ascii')).hexdigest() + return sha3_256(x.encode('ascii')).hexdigest() # Storage could be done by using a separator but is it optimal? In fact how to do a separator optimally in binary? Could for instance encode on two bits, for normal bits the first one should be 0 otherwise if the first is 1 then whatever the second bit, it's a separator. # TODO: sure that this function is meaningly correct? cf below comment, should also consider the serialization of the actual array - should in a similar way verify `ENTRIES_NUMBER` computation diff --git a/meta.py b/meta.py index a60cbb1..30c31ef 100755 --- a/meta.py +++ b/meta.py @@ -34,9 +34,6 @@ while True: write(prover, 'indexesRequest.txt') getProgramLine(prover) - with open('indexesRequest.txt') as f: - print(f.read()) - write(verifier, 'entries.txt') result = ' '.join(getProgramLine(verifier).split()[1:]) print(result)