Here are three small patches for rend-spec-ng. The first one tries to (hopefully) clarify how offline keys work, the second fixes a small typo in KEYBLIND, the third one clarifies how the rendezvous cookie is passed to the HS.
>From b0edfa78151720eb3c6136156ab5af16408ab66c Mon Sep 17 00:00:00 2001 From: George Kadianakis <[email protected]> Date: Sun, 19 Jan 2014 16:15:54 +0000 Subject: [PATCH] Clarify a bit how offline keys work --- rend-spec-ng.txt | 44 +++++++++++++++++++++++++++++++------------- 1 file changed, 31 insertions(+), 13 deletions(-) diff --git a/rend-spec-ng.txt b/rend-spec-ng.txt index 616ff48..dbf6535 100644 --- a/rend-spec-ng.txt +++ b/rend-spec-ng.txt @@ -450,16 +450,29 @@ enable the use of older Tor nodes as rendezvous points and introduction points. -1.7. In more detail: Offline operation +1.7. In more detail: Keeping crypto keys offline - In this design, a hidden service's secret identity key may be stored - offline. It's used only to generate blinded identity keys, which are - used to sign descriptor signing keys. In order to operate a hidden - service, the operator can generate a number of descriptor signing - keys and their certifications (see [DESC-OUTER] and [ENCRYPTED-DATA] + In this design, a hidden service's secret identity key may be + stored offline. It's used only to generate blinded signing keys, + which are used to sign descriptor signing keys. + + In order to operate a hidden service, the operator can generate in + advance a number of blinded signing keys and descriptor signing + keys (and their credentials; see [DESC-OUTER] and [ENCRYPTED-DATA] below), and their corresponding descriptor encryption keys, and export those to the hidden service hosts. + As a result, in the scenario where the Hidden Service gets + compromised, the adversary can only impersonate it for a limited + period of time (depending on how many signing keys were generated + in advance). + [TODO: Define revocation mechanism?] + + It's important to not send the private part of the blinded signing + key to the Hidden Service since an attacker can derive from it the + secret master identity key. The secret blinded signing key should + only be used to create credentials for the descriptor signing keys. + 1.8. In more detail: Encryption Keys And Replay Resistance To avoid replays of an introduction request by an introduction point, @@ -478,21 +491,26 @@ Public/private keypairs defined in this document: Master (hidden service) identity key -- A master signing keypair - used as the identity for a hidden service. This key is not used - on its own to sign anything; it is only used to generate blinded - signing keys as described in [KEYBLIND] and [SUBCRED]. + used as the identity for a hidden service. This key is long + term and not used on its own to sign anything; it is only used + to generate blinded signing keys as described in [KEYBLIND] + and [SUBCRED]. The public key is encoded in the ".onion" + address according to [NAMING]. Blinded signing key -- A keypair derived from the identity key, used to sign descriptor signing keys. Changes periodically for each service. Clients who know a 'credential' consisting of the service's public identity key and an optional secret can derive - the public blinded identity key for a service. This key is used - as an index in the DHT-like structure of the directory system. + the public blinded identity key for a service. This key is used + as an index in the DHT-like structure of the directory system + (see [SUBCRED]). Descriptor signing key -- A key used to sign hidden service - descriptors. This is signed by blinded signing keys. Unlike + descriptors. This is signed by blinded signing keys. Unlike blinded signing keys and master identity keys, the secret part - of this key must be stored online by hidden service hosts. + of this key must be stored online by hidden service hosts. The + public part of this key is included in the unencrypted section + of HS descriptors (see [DESC-OUTER]). Introduction point authentication key -- A short-term signing keypair used to identify a hidden service to a given -- 1.7.10.4
>From 844f8a05cd9e9b4494ce6c42753c6f4faa675c3d Mon Sep 17 00:00:00 2001 From: George Kadianakis <[email protected]> Date: Sun, 19 Jan 2014 16:19:07 +0000 Subject: [PATCH] Fix small typo in KEYBLIND --- rend-spec-ng.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rend-spec-ng.txt b/rend-spec-ng.txt index dbf6535..951d452 100644 --- a/rend-spec-ng.txt +++ b/rend-spec-ng.txt @@ -1653,7 +1653,7 @@ Appendix A. Signature scheme with key blinding [KEYBLIND] blinding factor h as H(A | s, B, N), and let: private key for the period: a' = h a - public key for the period: A' = h' A = (ha)B + public key for the period: A' = h A = (ha)B Generating a signature of M: given a deterministic random-looking r (see EdDSA paper), take R=rB, S=r+hash(R,A',M)ah mod l. Send signature -- 1.7.10.4
>From cf7520d70201637ef628ff29988a0922c5e34c7b Mon Sep 17 00:00:00 2001 From: George Kadianakis <[email protected]> Date: Sat, 4 Jan 2014 20:19:49 +0200 Subject: [PATCH] Make the rendezvous-cookie passing more explicit. It's not clear that REND_TOKEN refers to the rendezvous cookie. --- rend-spec-ng.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/rend-spec-ng.txt b/rend-spec-ng.txt index 616ff48..6c4eadf 100644 --- a/rend-spec-ng.txt +++ b/rend-spec-ng.txt @@ -1228,7 +1228,7 @@ The decrypted plaintext must have the form: - REND_TOKEN [20 bytes] + RENDEZVOUS_COOKIE [20 bytes] Any number of times: EXT_FIELD_TYPE [1 byte] EXT_FIELD_LEN [1 byte] @@ -1500,6 +1500,9 @@ HANDSHAKE_INFO [variable; depends on handshake type used.] + where RENDEZVOUS_COOKIE is the cookie suggested by the client + during the introduction (see [PROCESS_INTRO2]). + If the cookie matches the rendezvous cookie set on any not-yet-connected circuit on the rendezvous point, the rendezvous point connects the two circuits, and sends a RENDEZVOUS2 cell to the -- 1.7.10.4
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
