ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-04-25 05:19:53 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

copy edits and another option for tubID length

Browse Source
This commit is contained in:
Jean-Paul Calderone 2018-05-22 08:27:31 -04:00
parent b73e95ec30
commit c321c937f6
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
docs/proposed/http-storage-node-protocol.rst
View File

@ -107,13 +107,16 @@ Bob's client and Alice's storage node are assured of both **message authenticati
.. note:: .. note::
I think Foolscap TubIDs are 20 bytes and base32 encode to 32 bytes. Foolscap TubIDs are 20 bytes (SHA1 digest of the certificate).
SPKI information discussed here is 32 bytes and base32 encodes to 52 bytes. They are presented with base32 encoding at a length of 32 bytes.
https://tools.ietf.org/html/rfc7515#appendix-C may prove a better choice for encoding the information into a fURL. SPKI information discussed here is 32 bytes (SHA256 digest).
They will present in base32 as 52 bytes.
https://tools.ietf.org/html/rfc7515#appendix-C may prove a better (more compact) choice for encoding the information into a fURL.
It will encode 32 bytes into merely 43... It will encode 32 bytes into merely 43...
We could also choose to reduce the hash size of the SPKI information through use of another cryptographic hash (replacing sha256). We could also choose to reduce the hash size of the SPKI information through use of another cryptographic hash (replacing sha256).
A 224 bit hash function (SHA3-224, for example) might be suitable - A 224 bit hash function (SHA3-224, for example) might be suitable -
improving the encoded length to 38 bytes. improving the encoded length to 38 bytes.
Or we could stick with the Foolscap digest function - SHA1.
Transition Transition