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]
parent
d04cab58f7
commit
ab0139cc1c
|
@ -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
|
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
|
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
|
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
|
relative to the scheme above whenever K > T. The advantage would be simplifying
|
||||||
process. It is highly unlikely that there is any public key algorithm
|
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
|
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,
|
hashes than public keys, the H(pubkey) design above gives us shorter read caps,
|
||||||
although they are not shorter than using semi-private keys.
|
although they are not shorter than using semi-private keys.
|
||||||
|
|
Loading…
Reference in a new issue