[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