Should support change of hash functions

[ruudud]

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.

[Zerqent]

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

[Zerqent]

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

[Zerqent]

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]

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

[zooko]

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.