write some words about lease renewal secrets #1118
Conversation
| * the string itself | ||
| * ``","`` | ||
|
|
||
| * The **sha256d digest** is the **sha256 digest** of the **sha256 digest** of a string. |
There was a problem hiding this comment.
This whole section would be a lot clearer if there was also some code included to demonstrate (with type annotations).
There was a problem hiding this comment.
something like this?
"""
This is a reference implementation of the lease renewal secret derivation
protocol in use by Tahoe-LAFS clients as of 1.16.0.
"""
from base64 import (
b32encode,
)
from allmydata.util.hashutil import (
tagged_hash,
tagged_pair_hash,
)
def derive_renewal_secret(lease_secret: bytes, storage_index: bytes, tubid: bytes) -> bytes:
assert len(lease_secret) == 32
assert len(storage_index) == 20
assert len(tubid) == 20
bucket_renewal_tag = b"allmydata_bucket_renewal_secret_v1"
file_renewal_tag = b"allmydata_file_renewal_secret_v1"
client_renewal_tag = b"allmydata_client_renewal_secret_v1"
client_renewal_secret = tagged_hash(lease_secret, client_renewal_tag)
file_renewal_secret = tagged_pair_hash(
file_renewal_tag,
client_renewal_secret,
storage_index,
)
peer_id = b32encode(tubid).lower().strip(b"=")
return tagged_pair_hash(bucket_renewal_tag, file_renewal_secret, peer_id)
print(derive_renewal_secret(
b"lease secretxxxxxxxxxxxxxxxxxxxx",
b"storage indexxxxxxxx",
b"tub idxxxxxxxxxxxxxx",
))
I'm not really sure where to put it, though, or what kind of quality control to try to apply to it ... I suppose I could try to observe a few derived renewal secrets from the actual client software and then capture them as test vectors ... But that code isn't exactly easy to invoke.
There was a problem hiding this comment.
Yeah that is what I was thinking. You could just put it after the prose section.
I was able to validate that implementation by looking at existing code, other than the logic that calculates peer_id. But... that logic doesn't match the prose spec anyway, since it's supposed to be based on x509 certificate, not tub ID? So if you fix that line I think it's fine.
There was a problem hiding this comment.
The tubid is the sha1 hash of the x509 certificate. So I think it works out correctly the way I implemented it above. It's true that "tubid" is a Foolscap concept and the code that computes it is in Foolscap.
I didn't feel like grabbing cryptography and making the certificate an input to this function. The tubid is currently quite convenient to find (it's in every storage fURL) and that won't immediately change even after we drop Foolscap (because Tahoe will have to be capable of accepting fURLs for a long, long time).
So I'd like to leave this as-is is for now but I would be happy to see it revisited in the near future to scrub all traces of Foolscap from the spec.
I think that's fair. I'd love to use a better tool for this but I'm not really familiar with any. The convention in Tahoe seems to be to draw a picture and I'm not really up for that either. I added the reference implementation along with some test vectors showing it agrees with the current version of Tahoe. |
|
CI isn't done but it seems to be because GitHub Actions wedged itself. I'm not gonna bother waiting for it to sort itself out. |
https://tahoe-lafs.org/trac/tahoe-lafs/ticket/3774