[tahoe-dev] "Elk Point" design for mutable, add-only, and immutable files

Shawn Willden shawn at willden.org
Wed Sep 16 11:17:30 PDT 2009


On Tuesday 15 September 2009 09:57:15 pm David-Sarah Hopwood wrote:
> <http://jacaranda.org/tahoe/mutable-addonly-elkpoint-3.svg>
>
> I'll explain it in more detail tomorrow. I dropped the ability to have
> write-only caps that do not allow reading, so only needed symmetric
> encryption.

One thing that has confused me about your diagrams is the role of V in the 
signature operation that generates "a SigC".  It says that V is the "key", 
which I would think means it's the signing key -- but what, then is KC_sign 
for?

What makes sense to me is that V = KC_verify and KC_sign are an asymmetric key 
pair, and that the signing operation does not really involve V.  If that's 
correct, I think you should move the 'key' label to the arrow from KC_sign 
and remove the arrow from V.  It might also be clearer to change the label on 
V to KC_verify, and eliminate the "V = KC_verify" text.

Another relationship that perhaps should be made more clear is the 
relationship between S and KR_sign.  If I understand it correctly, they are 
another asymmetric key pair.

However, your comment that you only need symmetric encryption for this version 
would indicate that I don't understand any of what I think I understand, 
because I don't see how you can accomplish the goals of either Sig_KR or a 
SigC, as I understand them, without asymmetric encryption.

	Shawn.


More information about the tahoe-dev mailing list