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

[Ben Laurie]

Brian Warner wrote:
>> 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

If you want to use this technique, then probably you should use an 
error-propagating mode such as IGE and put the check string at the end. 
Note, btw, that IGE is not secure against deliberate attacks (i.e. it is 
not hard to manufacture incorrect ciphertexts that pass the check), but 
is fine against errors.

> 
> 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.

If you record the IV, then surely it doesn't matter where you start?

> 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
> _______________________________________________
> tahoe-dev mailing list
> tahoe-dev at allmydata.org
> http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
> 
> 


-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff