From ab0139cc1cec644b54b8fbab12f76f3387b9eb39 Mon Sep 17 00:00:00 2001
From: davidsarah <>
Date: Wed, 11 Jan 2012 21:41:35 +0000
Subject: [PATCH] previous change to statement about readcap length in the
 'pubkey in cap' scheme was incorrect. also the advantage is only
 simplification, not speedup, because the signature verification can be in
 done concurrently

[Imported from Trac: page NewMutableEncodingDesign, version 22]
---
 NewMutableEncodingDesign.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/NewMutableEncodingDesign.md b/NewMutableEncodingDesign.md
index 8156fda..c704288 100644
--- a/NewMutableEncodingDesign.md
+++ b/NewMutableEncodingDesign.md
@@ -178,8 +178,8 @@ requiring the client to fetch a copy:
 The hash to obtain the privkey is necessary because directly using a (K+T)-bit
 exponent would allow meet-in-the-middle attacks. ECDSA or Ed25519 pubkeys are
 slightly more than 2*K long, so this would increase the length of the readcaps
-because 2*K > T. The advantage would be simplifying/speeding up the download
-process. It is highly unlikely that there is any public key algorithm
+relative to the scheme above whenever K > T. The advantage would be simplifying
+the download process. It is highly unlikely that there is any public key algorithm
 with keys shorter than 2*K for a K-bit security level. Since we can use shorter
 hashes than public keys, the H(pubkey) design above gives us shorter read caps,
 although they are not shorter than using semi-private keys.