[tahoe-dev] protecting against bugs in our own crypto code

[Brian Warner]

> Fortunately, we can have both integrity-check on the plaintext, and  
> immunity to the question of such attacks by using a MAC instead of a  
> secure hash, where the MAC key is (derived from) the encryption key.   
> As a bonus, we can get reduced CPU usage and smaller Capability  
> Extension Blocks compared to a secure hash of the plaintext by using  
> the modern Carter-Wegman MAC such as Poly1305-AES or VMAC-AES-128.

Two other alternatives we might consider:

 encrypt the plaintext hash(es)

 add a checkstring at the beginning of the plaintext, verify it on decrypt

The latter would only guard against massive AES failures, such as the
encryption key being wrong.

One design goal is to allow us to verify the hashes one segment at a time.
This is the reason for the plaintext/ciphertext merkle trees. If we go with a
MAC or an encrypted hash, we need to make sure we build a merkle tree out of
them to retain this property.

> Another improvement to our process might be to have the Tahoe tests  
> run the pycryptopp tests, as suggested by Ben Laurie, or at least to  
> add a "check if pycryptopp's AES is working" test to the Tahoe tests.

Yeah, maybe we could copy a small subset of the pycryptopp tests into tahoe,
specifically to detect this bug.

> Another improvement, also suggested by Ben Laurie, would be to  
> eliminate the "default iv" feature from pycryptopp.  I'm working on a  
> new version of pycryptopp, so I'll look at that issue.

Nathan was asking about this too. Earlier versions of pycryptopp did not
provide control over this value (which is used as the initial offset for the
CTR-mode encryption). Subsequent work in Tahoe created a need for this
control, specifically resuming an interrupted helper upload (since we don't
want to re-encrypt the first half of the file that has already been pushed to
the helper, instead we'd like to start in the middle of the file, where
IV!=0). But the vast majority of the users of pycryptopp's AES-CTR mode are
encrypting multiple blocks of data in-order, and an API which supports this
easily (such as IV=0 for the first call and auto-incrementing it for each
block processed) will be easier and more reliable to use.

Apart from the backwards-compatibility issues that it would raise, I'm
uncertain if an API which required that IV= be provided with every call to
process() would work very well.

An API that required IV= be provided to the AES() constructor would work, but
of course we'd have to change the half a dozen places that Tahoe uses it to
add IV=0, and then Tahoe-1.0.0 (or other applications written against the old
version of pycryptopp) would not work with the latest one.


cheers,
 -Brian