[tor-commits] [torspec/master] Clarify a bit how offline keys work
nickm at torproject.org
nickm at torproject.org
Tue Jan 21 19:46:26 UTC 2014
commit d344dbb73493cb31118c7ee69e57e59ede5196d1
Author: George Kadianakis <desnacked at riseup.net>
Date: Tue Jan 21 14:41:17 2014 -0500
Clarify a bit how offline keys work
---
proposals/224-rend-spec-ng.txt | 44 ++++++++++++++++++++++++++++------------
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 055f171..e2fd1a4 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -453,16 +453,29 @@ Status: Draft
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,
@@ -481,21 +494,26 @@ Status: Draft
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
More information about the tor-commits
mailing list