[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor
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 <desnacked@xxxxxxxxxx>
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 <desnacked@xxxxxxxxxx>
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 <desnacked@xxxxxxxxxx>
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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev