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

[zooko]

On May 6, 2008, at 2:01 PM, 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)

Why would this be better than a MAC?

A fair answer would be "Because we understand secure hashes and  
encryption better than we understand MACs, and other people do, too.".

Is that what you were thinking?

Hm...  Actually, we would like for people without read-capability,  
but with only verify-capability to be able to verify this integrity  
check, right?  So then the secret key for the MAC, or equivalently  
the encryption key for encrypting the hash, should perhaps be  
associated with the verify cap rather than with the read-cap.  But of  
course the verify cap is (currently) public.

Hm.  This is hard to think about.


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

Perhaps we should distinguish between a cryptographic integrity check  
and a "runtime-self-check".  If we did that, then someone might, for  
example, watch a whole movie while relying on a secure hash Merkle  
tree for integrity of the movie, only at the end to get an internal  
self-check error saying that, while the crypto checked out, the  
redundant MAC on the flat plaintext didn't.  Would that be okay?   
(This could happen only if there were a bug in our crypto, or a bug  
in our self-check, or an attack on the secure hashes but not on the  
MAC.)

Something else that perhaps we should distinguish is different  
capabilities which are partly extruded into the Capability Extension  
Block.  There are two levels of privilege for immutable files: read  
(which gives you the plaintext) and verify (which gives you the  
ability to verify that the ciphertext is correct but not the ability  
to read the plaintext).  There are three levels of mutable files:  
write, read, and verify.  There is discussion about other kinds of  
privilege that we might want to separate: deep-verify separate from  
verify and shallow-read-only separate from deep-read-only have been  
proposed.

It might make sense to ask, for each thing in the Capability  
Extension Block, "Which capability is *this* thing part of?".

Regards,

Zooko