Changes between Version 9 and Version 10 of NewMutableEncodingDesign

Timestamp:

2010-01-07T07:34:46Z (14 years ago)

Author:

davidsarah

Comment:

clarify which schemes depend on ECDSA (short public keys) and which don't

NewMutableEncodingDesign

@@ -113 +113 @@
  * (1K) writecap = K-bit random string (perhaps derived from user-supplied
    material) (remember, K=kappa, probably 128bits)
- * (2K) readcap = 2*K-bit semiprivate key
+ * (minimum 2K) readcap = minimum 2*K-bit semiprivate key
  * verifycap = 2*K-bit public key
  * storage-index = truncated verifycap
@@ -131 +131 @@
 
  * (1K) writecap = K-bit random string
- * (2K) readcap = 2*K-bit first semiprivate key
- * (2K) traversalcap = 2*K-bit second semiprivate key
+ * (minimum 2K) readcap = minimum 2*K-bit first semiprivate key
+ * (minimum 2K) traversalcap = minimum 2*K-bit second semiprivate key
  * verifycap = 2*K-bit public key
  * storage-index = truncated verifycap
@@ -140 +140 @@
 child verifycap/traversalcaps.
 
-== ECDSA, no semi-private keys, no traversalcap ==
+== Any public key algorithm, no semi-private keys, no traversalcap ==
 
 Without semi-private keys, we need something more complicated to protect the
@@ -161 +161 @@
 resistance. The verifycap is 2*K.
 
-=== include pubkey in cap ===
+=== include ECDSA pubkey in cap ===
 
 Or, if the pubkey is short enough, include it in the cap rather than
@@ -177 +177 @@
 give us slightly shorter keys.
 
-=== add traversalcap ===
+=== Any public key algorithm, no semi-private keys, with traversalcap ===
 
 Since a secure pubkey identifier (either H(pubkey) or the original privkey)