Should support change of hash functions #1213

New Issue

tahoe-lafs · 2010-09-28T12:24:30Z

ruudud commented

2010-09-28 12:24:30 +00:00

It should be relatively easy to change e.g. SHA-256d to other hash functions.

When doing the following in util/hashutil.py, several tests break:

from pycryptopp.hash.sha256 import SHA256

from sha3 import BlueMidnightWish as SHA256

BlueMidnightWish is one of the 14 remaining candidates of the NIST SHA-3 competition, and the implementation tested has an output of 256 bits.

The tests probably contains fixtures that have been created using SHA-256, but none the less, attached is the output from the tests.

That simple import trick is enough to get immutable file upload to work, but at least mutable files and the webgui fail.

It should be relatively easy to change e.g. SHA-256d to other hash functions. When doing the following in util/hashutil.py, several tests break: # from pycryptopp.hash.sha256 import SHA256 from sha3 import [BlueMidnightWish](wiki/BlueMidnightWish) as SHA256 [BlueMidnightWish](wiki/BlueMidnightWish) is one of the 14 remaining candidates of the NIST SHA-3 competition, and the implementation tested has an output of 256 bits. The tests probably contains fixtures that have been created using SHA-256, but none the less, attached is the output from the tests. That simple import trick is enough to get immutable file upload to work, but at least mutable files and the webgui fail.

tahoe-lafs added the

labels 2010-09-28 12:24:30 +00:00

tahoe-lafs added this to the undecided milestone 2010-09-28 12:24:30 +00:00

Zerqent commented

2010-09-28 12:26:47 +00:00

Attachment output.txt (33220 bytes) added

test results (dies with terminate called after throwing an instance of 'CryptoPP::BERDecodeErr' what(): BER decode error afterwards)

**Attachment** output.txt (33220 bytes) added test results (dies with terminate called after throwing an instance of 'CryptoPP::BERDecodeErr' what(): BER decode error afterwards)

output.txt

32 KiB

Zerqent commented

2010-09-28 12:27:26 +00:00

Attachment incident-2010-09-28-133604-c6mrjji.flog.bz2 (5963 bytes) added

incident-log after creating the default alias and trying to create a directory

**Attachment** incident-2010-09-28-133604-c6mrjji.flog.bz2 (5963 bytes) added incident-log after creating the default alias and trying to create a directory

incident-2010-09-28-133604-c6mrjji.flog.bz2

5.8 KiB

Zerqent commented

2010-09-28 12:28:26 +00:00

Console output:

tahoe mkdir test
Error during HTTP request: 500 Internal Server Error
"Traceback (most recent call last):\x0aFailure: allmydata.mutable.common.UncoordinatedWriteError: \x0a"

Testing is done with a single client (shares happy/needed/total set to 1) and introducer.

Console output: tahoe mkdir test Error during HTTP request: 500 Internal Server Error "Traceback (most recent call last):\x0aFailure: allmydata.mutable.common.UncoordinatedWriteError: \x0a" Testing is done with a single client (shares happy/needed/total set to 1) and introducer.

davidsarah commented

2010-09-29 01:45:36 +00:00

Some tests involve loading shares generated by previous versions, which should break with this import hack alone.

Some tests involve loading shares generated by previous versions, which *should* break with this import hack alone.

zooko commented

2010-09-29 05:09:59 +00:00

Replying to davidsarah:

Some tests involve loading shares generated by previous versions, which should break with this import hack alone.

Agreed—those ones should go red with this hack alone.

To make a version of this patch which does not turn those tests red (and is thus one step closer to being accepted into trunk), define a new type of capability which will use BMW-256 instead of SHA-256. Ticket #1164 describes how to do that in order to make a capability that uses XSalsa20+AES-128 instead of using AES-256. The same sort of patch would serve to make a type of capability which uses BMW-256 instead of SHA-256.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/1213#issuecomment-80335): > Some tests involve loading shares generated by previous versions, which *should* break with this import hack alone. Agreed—those ones *should* go red with this hack alone. To make a version of this patch which does not turn those tests red (and is thus one step closer to being accepted into trunk), define a new type of capability which will use BMW-256 instead of SHA-256. Ticket #1164 describes how to do that in order to make a capability that uses XSalsa20+AES-128 instead of using AES-256. The same sort of patch would serve to make a type of capability which uses BMW-256 instead of SHA-256.

Sign in to join this conversation.