ExternalVendorCode/tahoe-lafs
1
0
Fork 0
mirror of https://github.com/tahoe-lafs/tahoe-lafs.git synced 2025-01-19 03:06:33 +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::
I think Foolscap TubIDs are 20 bytes and base32 encode to 32 bytes.
SPKI information discussed here is 32 bytes and base32 encodes to 52 bytes.
https://tools.ietf.org/html/rfc7515#appendix-C may prove a better choice for encoding the information into a fURL.
Foolscap TubIDs are 20 bytes (SHA1 digest of the certificate).
They are presented with base32 encoding at a length of 32 bytes.
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...
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 -
improving the encoded length to 38 bytes.
Or we could stick with the Foolscap digest function - SHA1.
Transition