[tor-commits] [torspec/master] Revert "prop224: avoid replicas with the same blinded key"
asn at torproject.org
asn at torproject.org
Sun May 8 21:36:25 UTC 2016
commit f4026eec6858ff9e085b6c46224d7b0367d93cff
Author: George Kadianakis <desnacked at riseup.net>
Date: Tue Apr 12 15:14:07 2016 +0300
Revert "prop224: avoid replicas with the same blinded key"
This reverts commit 8df8c0584392240aa8fecbcd2164a4489be7ae1a.
---
proposals/224-rend-spec-ng.txt | 99 +++++++++++++++---------------------------
1 file changed, 34 insertions(+), 65 deletions(-)
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 384b941..237ffdd 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -375,10 +375,9 @@ Status: Draft
In order to download a descriptor, clients must know which blinded
signing key was used to sign it. (See the next section for more info
on key blinding.) This blinded signing key is derived from the
- service's public key, the descriptor replica number, and, optionally,
- an additional secret that is not part of the hidden service's onion
- address. The public key, replica number, and this secret together
- constitute the service's "credential".
+ service's public key and, optionally, an additional secret that is
+ not part of the hidden service's onion address. The public key and
+ this secret together constitute the service's "credential".
When the secret is in use, the hidden service gains protections
equivalent to the "stealth mode" in previous designs.
@@ -418,19 +417,19 @@ Status: Draft
positions based on the key that was used to sign them. Note that
hidden service descriptors are not signed with the services' public
keys directly. Instead, we use a key-blinding system [KEYBLIND] to
- create new keys-of-the-day for the descriptor replicas for each
- hidden service. Any client that knows the hidden service's credential
- can derive these blinded signing keys for a given period. It should be
- impossible to derive the blinded signing keys lacking that credential.
+ create a new key-of-the-day for each hidden service. Any client that
+ knows the hidden service's credential can derive these blinded
+ signing keys for a given period. It should be impossible to derive
+ the blinded signing key lacking that credential.
The body of each descriptor is also encrypted with a key derived from
the credential.
To avoid a "thundering herd" problem where every service generates
and uploads a new descriptor at the start of each period, each
- descriptor replica comes online at a time during the period that
- depends on its blinded signing key. The keys for the last period remain
- valid until the new keys come online.
+ descriptor comes online at a time during the period that depends on
+ its blinded signing key. The keys for the last period remain valid
+ until the new keys come online.
1.5. In more detail: Scaling to multiple hosts
@@ -468,9 +467,9 @@ Status: Draft
in advance).
[TODO: Define revocation mechanism?]
- It's important to not send the private part of a blinded signing
+ 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. A secret blinded signing key should
+ 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
@@ -503,16 +502,14 @@ Status: Draft
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
- (see [SUBCRED]). Each descriptor replica may use a different
- blinded signing key, based on its replicanum.
+ (see [SUBCRED]).
Descriptor signing key -- A key used to sign hidden service
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. The
public part of this key is included in the unencrypted section
- of HS descriptors (see [DESC-OUTER]). Each descriptor replica must
- use a different descriptor signing key.
+ of HS descriptors (see [DESC-OUTER]).
Introduction point authentication key -- A short-term signing
keypair used to identify a hidden service to a given
@@ -533,8 +530,7 @@ Status: Draft
Descriptor encryption keys -- A symmetric encryption key used to
encrypt the body of hidden service descriptors. Derived from the
- current period, the descriptor replica, the descriptor revision,
- and the hidden service credential.
+ current period and the hidden service credential.
Public/private keypairs defined elsewhere:
@@ -565,8 +561,6 @@ Status: Draft
periods), a hidden service host uses a different blinded private key
to sign its directory information, and clients use a different
blinded public key as the index for fetching that information.
- Each descriptor replica for each service may use different blinded
- keys.
For a candidate for a key derivation method, see Appendix [KEYBLIND].
@@ -583,13 +577,7 @@ Status: Draft
The subcredential for a period is derived as:
H("subcredential" |
credential |
- blinded-public-key(replica-keynum)).
-
- Where replica-keynum = replicanum % hsdir_num_replica_keys.
- (This ensures that each replica has a blinded key, even if
- hsdir_num_replicas is higher than hsdir_num_replica_keys. This ensures
- hidden services can't predict future values of hsdir_num_replicas at
- key blinding time.)
+ blinded-public-key).
2.2. Locating, uploading, and downloading hidden service descriptors
[HASHRING]
@@ -597,9 +585,7 @@ Status: Draft
To avoid attacks where a hidden service's descriptor is easily
targeted for censorship, we store them at different directories over
time, and use shared random values to prevent those directories from
- being predictable far in advance. Each descriptor replica may use a
- different blinded signing key, which prevents directories in one
- replica locating directories in other replica(s).
+ being predictable far in advance.
Which Tor servers hosts a hidden service depends on:
@@ -660,8 +646,7 @@ Status: Draft
The time at which a key from the next interval becomes valid is
determined by taking the first two bytes of
- OFFSET = H("interval-offset" | blinded-public-key(replica-keynum) |
- INT_8(Next_Period_Num))
+ OFFSET = H("interval-offset" | Key | INT_8(Next_Period_Num))
as a big-endian integer, dividing by 65536, and treating that as a
fraction of the overlap interval.
@@ -682,21 +667,11 @@ Status: Draft
2.2.3. Where to publish a service descriptor
- The following constant controls how many blinded keys are created
- per period for the different descriptor replicas:
-
- hsdir_num_replica_keys = an integer constant 2.
-
- (Since blinded keys can be generated ahead of time, a service can not
- know the value of hsdir_n_replicas at the time the blinded keys will
- be used. If hsdir_n_replicas is greater than hsdir_num_replica_keys,
- some keys will be used for multiple replicas.)
-
The following consensus parameters control where a hidden service
descriptor is stored;
hsdir_n_replicas = an integer in range [1,16]
- with default value hsdir_num_replica_keys.
+ with default value 2.
hsdir_spread_fetch = an integer in range [1,128]
with default value 3.
@@ -708,12 +683,12 @@ Status: Draft
with default value 12.
To determine where a given hidden service descriptor will be stored
- in a given period, after the blinded public key for that period and
- replica is derived, the uploading or downloading party calculates:
+ in a given period, after the blinded public key for that period is
+ derived, the uploading or downloading party calculate
for replicanum in 1...hsdir_n_replicas:
hs_index(replicanum) = H("store-at-idx" |
- blinded_public_key(replica-keynum) |
+ blinded_public_key |
INT_8(replicanum) |
INT_8(periodnum) )
@@ -721,8 +696,7 @@ Status: Draft
periodnum is defined in section TIME-PERIODS.
where n_replicas is determined by the consensus parameter
- "hsdir_n_replicas", and replica-keynum is replicanum %
- hsdir_num_replica_keys.
+ "hsdir_n_replicas".
Then, for each node listed in the current consensus with the HSDir3
flag, we compute a directory index for that node as:
@@ -772,7 +746,7 @@ Status: Draft
/tor/rendezvous3/publish relative to the hidden service directory's
root, and downloaded with an HTTP GET request for the URL
/tor/rendezvous3/<z> where z is a base-64 encoding of the hidden
- service's blinded public key for the replica.
+ service's blinded public key.
[TODO: raw base64 is not super-nice for URLs, since it can have
slashes. We already use it for microdescriptor URLs, though. Do we
@@ -838,9 +812,8 @@ Status: Draft
The 'certificate' field contains a certificate in the format from
proposal 220, with the short-term ed25519 descriptor-signing key
- for the replica, signed by the blinded public key for the replica.
- It must contain a ed25519-signing-key extension containing the
- blinded public key for the replica.
+ signed by the blinded public key. It must contain a
+ ed25519-signing-key extension containing the blinded public key.
"revision-counter" SP Integer NL
@@ -870,7 +843,7 @@ Status: Draft
A signature of all previous fields, using the signing key in the
hs-descriptor line. We use a separate key for signing, so that
the hidden service host does not need to have its private blinded
- keys online.
+ key online.
2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA]
@@ -888,9 +861,8 @@ Status: Draft
[ XX/teor - is the extra load on the HSDirs worth it? ]
- secret_input = blinded_public_key(replica-keynum) |
- subcredential | INT_4(revision_counter)
- keys = KDF(secret_input | salt | "hsdir-encrypted-data",
+ secret_input = blinded_public_key | subcredential | INT_4(revision_counter)
+ keys = KDF(secret_input, salt, "hsdir-encrypted-data",
S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN)
SECRET_KEY = first S_KEY_LEN bytes of keys
@@ -949,10 +921,9 @@ Status: Draft
Base-64 encoded introduction point authentication key that was
used to establish introduction point circuit, cross-certifying
- the blinded public key for the replica. This uses the
- certificate format of proposal 220 with type [09]. The
- signing-key extension is mandatory here to tell you what the
- public key is.
+ the blinded public key. This uses the certificate format of
+ proposal 220 with type [09]. The signing-key extension is
+ mandatory here to tell you what the public key is.
"enc-key" SP "ntor" SP key NL
@@ -1686,10 +1657,8 @@ Appendix A. Signature scheme with key blinding [KEYBLIND]
possible alternatives. Also, see [KEYBLIND-PROOF] for a security
proof of this scheme.
- (To use this with Tor, set N(replica-keynum) = "key-blind" |
- INT_8(period-number) | INT_8(Start of period in seconds since epoch) |
- INT_1(replica-keynum), where replica-keynum is from 1 to
- hsdir_num_replica_keys.)
+ (To use this with Tor, set N = "key-blind" | INT_8(period-number) |
+ INT_8(Start of period in seconds since epoch).)
Appendix B. Selecting nodes [PICKNODES]
More information about the tor-commits
mailing list