On Mon, Aug 10, 2020 at 09:00:32AM -0400, Nick Mathewson wrote: > On Wed, Jul 29, 2020 at 1:15 AM Matthew Finkel <[email protected]> wrote: > > > > Hello everyone, > > Hi, Matt! > > There's a part of this that I'm still trying to figure out: > > > The safest usage of the long-term keys for alternative purposes I see > > appears to be by deriving a (fixed/deterministic) blinded key pair using > > the same scheme that Tor uses, and signing/verification simply follow > > the same process as Tor, except the derived keys need not rotate > > periodically (is this true?). The derived key should be used for > > certifying a freshly generated ed25519 key, which is used in the > > application protocol. For example, if I want to use a key for code > > signing such that it is bound to my onion service key, then I could > > derive a certifying key by following Tor's derivation scheme, by > > substituting: > > > > BLIND_STRING = "Derive temporary signing key" | INT_1(0) > > N = "key-blind" | INT_8(period-number) | INT_8(period_length) > > > > with > > > > BLIND_STRING = "Derive code signing key" | INT_1(0) > > N = "code-sigining-key-blind" | "v0" | "YYYY-MM-DD" | > > INT_8(validity_period) > > In the case of v3 onion services, 'period-number' comes from the > current time, and 'period-length' comes from the consensus, so it's > easy for the client to know what parameters to use when deriving the > key. > > But how is the party that relies on the derived key supposed to know > what values were used for "YYYY-MM-DD" and "validity period" in this > case? It seems like those two values would need to be shipped along > with the key, which could make for logistical issues.
I was imagining "just serialize it in the public key". The public key would grow by a few more characters, but not too much. In this case, we'd probably want a defined (extensible) structure for the public key rather than each application defining their own arbitrary format, but I didn't get that far in thinking about it. _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
