[tor-commits] [torspec/master] Add the common hybrid handshake proposal and assign it a number.
isis at torproject.org
isis at torproject.org
Fri Jul 22 11:51:24 UTC 2016
commit cd8ad93af019346502ae71c4268d49e49882a448
Author: Isis Lovecruft <isis at torproject.org>
Date: Fri Jul 22 11:46:30 2016 +0000
Add the common hybrid handshake proposal and assign it a number.
---
proposals/000-index.txt | 2 +
proposals/269-hybrid-handshake.txt | 412 +++++++++++++++++++++++++++++++++++++
proposals/proposal-status.txt | 5 +
3 files changed, 419 insertions(+)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index 180ba4e..316ac32 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -189,6 +189,7 @@ Proposals by number:
266 Removing current obsolete clients from the Tor network [DRAFT]
267 Tor Consensus Transparency [DRAFT]
268 New Guard Selection Behaviour [DRAFT]
+269 Transitionally secure hybrid handshakes [DRAFT]
Proposals by status:
@@ -215,6 +216,7 @@ Proposals by status:
266 Removing current obsolete clients from the Tor network
267 Tor Consensus Transparency
268 New Guard Selection Behaviour
+ 269 Transitionally secure hybrid handshakes
NEEDS-REVISION:
190 Bridge Client Authorization Based on a Shared Secret
NEEDS-RESEARCH:
diff --git a/proposals/269-hybrid-handshake.txt b/proposals/269-hybrid-handshake.txt
new file mode 100644
index 0000000..0fbaae0
--- /dev/null
+++ b/proposals/269-hybrid-handshake.txt
@@ -0,0 +1,412 @@
+Filename: 269-hybrid-handshake.txt
+Title: Transitionally secure hybrid handshakes
+Author: John Schanck, William Whyte, Zhenfei Zhang,
+ Nick Mathewson, Isis Lovecruft, Peter Schwabe
+Created: 7 June 2016
+Updated: 22 July 2016
+Status: Draft
+
+
+1. Introduction
+
+ This document describes a generic method for integrating a post-quantum key
+ encapsulation mechanism (KEM) into an ntor-like handshake. A full discussion
+ of the protocol and its proof of security may be found in [SWZ16].
+
+ 1.1 Motivation: Transitional forward-secret key agreement
+
+ All currently deployed forward-secret key agreement protocols are
+ vulnerable to quantum cryptanalysis. The obvious countermeasure is to
+ switch to a key agreement mechanism that uses post-quantum primitives for
+ both authentication and confidentiality.
+
+ This option should be explored, but providing post-quantum router
+ authentication in Tor would require a new consensus method and new
+ microdescriptor elements. Since post-quantum public keys and signatures can
+ be quite large, this may be a very expensive modification.
+
+ In the near future it will suffice to use a "transitional" key agreement
+ protocol -- one that provides pre-quantum authentication and post-quantum
+ confidentiality. Such a protocol is secure in the transition between pre-
+ and post-quantum settings and provides forward secrecy against adversaries
+ who gain quantum computing capabilities after session negotiation.
+
+ 1.2 Motivation: Fail-safe plug & play for post-quantum KEMs
+
+ We propose a modular design that allows any post-quantum KEM to be included
+ in the handshake. As there may be some uncertainty as to the security of
+ the currently available post-quantum KEMs, and their implementations, we
+ ensure that the scheme safely degrades to ntor in the event of a complete
+ break on the KEM.
+
+
+2. Proposal
+
+ 2.1 Overview
+
+ We re-use the public key infrastructure currently used by ntor. Each
+ server publishes a static Diffie-Hellman (DH) onion key. Each client is
+ assumed to have a certified copy of each server's public onion key and each
+ server's "identity digest". To establish a session key, we propose that the
+ client send two ephemeral public keys to the server. The first is an
+ ephemeral DH key, the second is an ephemeral public key for a post-quantum
+ KEM. The server responds with an ephemeral DH public key and an
+ encapsulation of a random secret under the client's ephemeral KEM key. The
+ two parties then derive a shared secret from: 1) the static-ephemeral DH
+ share, 2) the ephemeral-ephemeral DH share, 3) the encapsulated secret, 4)
+ the transcript of their communication.
+
+ 2.2 Notation
+
+ Public, non-secret, values are denoted in UPPER CASE.
+ Private, secret, values are denoted in lower case.
+ We use multiplicative notation for Diffie-Hellman operations.
+
+ 2.3 Parameters
+
+ DH A Diffie-Hellman primitive
+ KEM A post-quantum key encapsulation mechanism
+ H A cryptographic hash function
+
+ LAMBDA (bits) Pre-quantum bit security parameter
+ MU (bits) 2*LAMBDA
+ KEY_LEN (bits) Length of session key material to output
+
+ H_LEN (bytes) Length of output of H
+ ID_LEN (bytes) Length of server identity digest
+ DH_LEN (bytes) Length of DH public key
+ KEM_PK_LEN (bytes) Length of KEM public key
+ KEM_C_LEN (bytes) Length of KEM ciphertext
+
+ PROTOID (string) "hybrid-[DH]-[KEM]-[H]-[revision]"
+ T_KEY (string) PROTOID | ":key"
+ T_AUTH (string) PROTOID | ":auth"
+
+ Note: [DH], [KEM], and [H] are strings that uniquely identify
+ the primitive, e.g. "x25519"
+
+ 2.4 Subroutines
+
+ HMAC(key, msg):
+ The pseudorandom function defined in [RFC2104] with H
+ as the underlying hash function.
+
+ EXTRACT(salt, secret):
+ A randomness extractor with output of length >= MU bits.
+
+ For most choices of H one should use the HMAC based
+ randomness extractor defined in [RFC5869]:
+ EXTRACT(salt, secret) := HMAC(salt, secret).
+
+ If MU = 256 and H is SHAKE-128 with MU bit output, or
+ if MU = 512 and H is SHAKE-256 with MU bit output, then
+ one may instead define:
+ EXTRACT(salt, secret) := H(salt | secret).
+
+ EXPAND(seed, context, len):
+ The HMAC based key expansion function defined in [RFC5869].
+ Outputs the first len bits of
+ K = K_1 | K_2 | K_3 | ...
+ where
+ K_0 = empty string (zero bits)
+ K_i = HMAC(seed, K_(i-1) | context | INT8(i)).
+
+ Alternatively, an eXtendable Output Function (XOF) may be used.
+ In which case,
+ EXPAND(seed, context, len) = XOF(seed | context, len)
+
+ DH_GEN() -> (x, X):
+ Diffie-Hellman keypair generation. Secret key x, public key X.
+
+ DH_MUL(P,x) -> xP:
+ Scalar multiplication in the DH group of the base point P by
+ the scalar x.
+
+ KEM_GEN() -> (sk, PK):
+ Key generation for KEM.
+
+ KEM_ENC(PK) -> (m, C):
+ Encapsulation, C, of a uniform random message m under public key PK.
+
+ KEM_DEC(C, sk):
+ Decapsulation of the ciphertext C with respect to the secret key sk.
+
+ KEYID(A) -> A or H(A):
+ For DH groups with long element presentations it may be desirable to
+ identify a key by its hash. For typical elliptic curve groups this should
+ be the identity map.
+
+ 2.5 Handshake
+
+ To perform the handshake, the client needs to know the identity digest and
+ an onion key for the router. The onion key must be for the specified DH
+ scheme (e.g. x25519). Call the router's identity digest "ID" and its public
+ onion key "A". The following Client Init / Server Response / Client Finish
+ sequence defines the hybrid-DH-KEM protocol. See Fig. 1 for a schematic
+ depiction of the same operations.
+
+ - Client Init ------------------------------------------------------------
+
+ The client generates ephemeral key pairs
+ x, X = DH_GEN()
+ esk, EPK = KEM_GEN().
+
+ The client sends a CREATE cell with contents:
+ ID [ID_LEN bytes]
+ KEYID(A) [H_LEN bytes]
+ X [DH_LEN bytes]
+ EPK [KEM_PK_LEN bytes]
+
+ - Server Response --------------------------------------------------------
+
+ The server generates an ephemeral x25519 keypair, computes both DH
+ shares, and encrypts a secret under KEM:
+ y, Y := DH_GEN()
+ s0 := H(DH_MUL(X,a))
+ s1 := DH_MUL(X,y)
+ s2, C := KEM_ENC(EPK)
+
+ The server then derives the pre-master secret and authentication tag:
+ secret := s0 | s1 | s2
+ SALT := ID | A | X | Y | EPK | C
+ seed := EXTRACT(SALT, secret)
+ AUTH := EXPAND(seed, T_AUTH, MU)
+
+ The server sends a CREATED cell with contents:
+ Y [DH_LEN bytes]
+ C [KEM_C_LEN bytes]
+ AUTH [CEIL(MU/8) bytes]
+
+ - Client Finish ----------------------------------------------------------
+
+ The client computes the three secret shares:
+ s0 := H(DH_MUL(A,x))
+ s1 := DH_MUL(Y,x)
+ s2 := KEM_DEC(C, esk)
+
+ The client then derives the pre-master secret:
+ secret := s0 | s1 | s2
+ SALT := ID | A | X | Y | EPK | C
+ seed := EXTRACT(SALT, secret);
+
+ The client verifies that AUTH == EXPAND(seed, T_AUTH, MU).
+
+ If the authentication check passes the client expands the seed
+
+ - Key derivation ---------------------------------------------------------
+
+ Both parties derive the shared key by expanding seed:
+
+ KEY := EXPAND(seed, T_KEY, KEY_LEN)
+
+ .--------------------------------------------------------------------------.
+ | Fig. 1: The hybrid-DH-KEM handshake. |
+ .--------------------------------------------------------------------------.
+ | |
+ | Initiator Responder with identity key ID |
+ | --------- --------- and onion key A |
+ | |
+ | x, X := DH_GEN() |
+ | esk, EPK := KEM_GEN() |
+ | CREATE_DATA := ID | A | X | EPK |
+ | |
+ | --- CREATE_DATA ---> |
+ | |
+ | y, Y := DH_GEN() |
+ | s0 := H(DH_MUL(X,a)) |
+ | s1 := DH_MUL(X,y) |
+ | s2, C := KEM_ENC(EPK) |
+ | secret := s0 | s1 | s2 |
+ | SALT := ID | A | X | Y | EPK | C |
+ | seed := EXTRACT(SALT, secret) |
+ | AUTH := EXPAND(seed, T_AUTH, MU) |
+ | KEY := EXPAND(seed, T_KEY, KEY_LEN) |
+ | CREATED_DATA := Y | C | AUTH |
+ | |
+ | <-- CREATED_DATA --- |
+ | |
+ | s0 := H(DH_MUL(A,x)) |
+ | s1 := DH_MUL(Y,x) |
+ | s2 := KEM_DEC(C, esk) |
+ | secret := s0 | s1 | s2 |
+ | SALT := ID | A | X | Y | EPK | C |
+ | seed := EXTRACT(SALT, secret) |
+ | |
+ | assert AUTH == EXPAND(seed, T_AUTH, MU) |
+ | KEY := EXPAND(seed, T_KEY, KEY_LEN) |
+ '--------------------------------------------------------------------------'
+
+
+3. Changes from ntor
+
+ The hybrid-null handshake differs from ntor in a few ways.
+
+ First there are some superficial differences.
+ The protocol IDs differ:
+ ntor PROTOID "ntor-curve25519-sha256-1",
+ hybrid-null PROTOID "hybrid-x25519-null-sha256-1",
+ and the context strings differ:
+ ntor T_MAC PROTOID | ":mac",
+ ntor T_KEY PROTOID | ":key_extract",
+ ntor T_VERIFY PROTOID | ":verify",
+ ntor M_EXPAND PROTOID | ":key_expand",
+ hybrid-null T_KEY PROTOID | ":key",
+ hybrid-null T_AUTH PROTOID | ":auth".
+
+ Then there are significant differences in how the authentication tag
+ (AUTH) and key (KEY) are derived. The following description uses the
+ HMAC based definitions of EXTRACT and EXPAND.
+
+ In ntor the server computes
+ secret_input := EXP(X,y) | EXP(X,a) | ID | A | X | Y | PROTOID
+ seed := HMAC(T_KEY, secret_input)
+ verify := HMAC(T_VERIFY, seed)
+ auth_input := verify | ID | A | Y | X | PROTOID | "Server"
+ AUTH := HMAC(T_MAC, auth_input)
+ KEY := EXPAND(seed, M_EXPAND, KEY_LEN).
+
+ In hybrid-null the server computes
+ secret_input := H(EXP(X,a)) | EXP(X,y)
+ SALT := ID | A | X | Y
+ seed := EXTRACT(SALT, secret_input)
+ AUTH := EXPAND(seed, T_AUTH, MU)
+ KEY := EXPAND(seed, T_KEY, KEY_LEN).
+
+ First, note that hybrid-null hashes EXP(X,a). This is due to
+ the fact that weaker assumptions were used to prove the security
+ of hybrid-null than were used to prove the security of ntor. While
+ this may seem artificial we recommend keeping it.
+
+ Second, ntor uses fixed HMAC keys for all sessions. This is unlikely
+ to be a security issue, but it makes a stronger assumption on HMAC
+ than if the order of the arguments were reversed.
+
+ Third, hybrid-null forgoes the use of auth_input (to see what we mean,
+ compare hybrid-null to ntor with auth_input := seed). The use of
+ auth_input in ntor is designed to prevent a certain type of collision
+ attack (see [Zav12, SZW16]). However the auth_input countermeasure is
+ unnecessary if the authentication tag is of length 2*LAMBDA. A collision
+ attack on a random function of output length 2*LAMBDA has cost 2^LAMBDA.
+
+
+4. Instantiation with NTRUEncrypt
+
+ This example uses the NTRU parameter set EESS443EP2 [XXX cite] which is
+ estimated at the 128 bit security level for both pre- and post-quantum
+ settings.
+
+ EES443EP2 specifies three algorithms:
+ EES443EP2_GEN() -> (sk, PK),
+ EES443EP2_ENCRYPT(m, PK) -> C,
+ EES443EP2_DECRYPT(C, sk) -> m.
+
+ The m parameter for EES443EP2_ENCRYPT can be at most 49 bytes.
+ We define EES443EP2_MAX_M_LEN := 49.
+
+ 0x0102 hybrid-x25519-ees443ep2-shake128-1
+ --------------------
+ DH := x25519
+ KEM := EES443EP2
+ H := SHAKE-128 with 256 bit output
+
+ LAMBDA := 128
+ MU := 256
+
+ H_LEN := 32
+ ID_LEN := 20
+ DH_LEN := 32
+ KEM_PK_LEN := 615
+ KEM_C_LEN := 610
+ KEY_LEN := XXX
+
+ PROTOID := "hybrid-x25519-ees443ep2-shake128-1"
+ T_KEY := "hybrid-x25519-ees443ep2-shake128-1:key"
+ T_AUTH := "hybrid-x25519-ees443ep2-shake128-1:auth"
+
+ Subroutines
+ -----------
+ EXTRACT(salt, secret) := SHAKE-128(salt | secret, MU)
+ EXPAND(seed, context, len) := SHAKE-128(seed | context, len)
+ KEM_GEN() := EES443EP2_GEN()
+ KEM_ENC(PK) := (s, C)
+ where s = RANDOMBYTES(EES443EP2_MAX_M_LEN)
+ and C = EES443EP2_ENCRYPT(s, PK)
+ KEM_DEC(C, sk) := EES443EP2_DECRYPT(C, sk)
+
+
+5. Instantiation with NewHope
+
+ [XXX write intro]
+
+ 0x0103 hybrid-x25519-newhope-shake128-1
+ --------------------
+ DH := x25519
+ KEM := NEWHOPE
+ H := SHAKE-128 with 256 bit output
+
+ LAMBDA := 128
+ MU := 256
+
+ H_LEN := 32
+ ID_LEN := 20
+ DH_LEN := 32
+ KEM_PK_LEN := 1824
+ KEM_C_LEN := 2048
+ KEY_LEN := XXX
+
+ PROTOID := "hybrid-x25519-newhope-shake128-1"
+ T_KEY := "hybrid-x25519-newhope-shake128-1:key"
+ T_AUTH := "hybrid-x25519-newhope-shake128-1:auth"
+
+ Subroutines
+ -----------
+ EXTRACT(salt, secret) := SHAKE-128(salt | secret, MU)
+ EXPAND(seed, context, len) -> SHAKE-128(seed | context, len)
+ KEM_GEN() -> (sk, PK)
+ where SEED := RANDOMBYTES(MU)
+ (sk,B) := NEWHOPE_KEYGEN(A_SEED)
+ PK := B | A_SEED
+ KEM_ENC(PK) -> NEWHOPE_ENCAPS(PK)
+ KEM_DEC(C, sk) -> NEWHOPE_DECAPS(C, sk)
+
+
+7. Versions
+
+ [XXX rewrite section w/ new versioning proposal]
+
+ Recognized handshake types are:
+ 0x0000 TAP -- the original Tor handshake;
+ 0x0001 reserved
+ 0x0002 ntor -- the ntor-x25519-sha256 handshake;
+
+ Request for new handshake types:
+ 0x010X hybrid-XX -- a hybrid of a x25519 handshake
+ and a post-quantum key encapsulation mechanism
+
+ where
+ 0x0101 hybrid-null -- No post-quantum key encapsulation mechanism.
+
+ 0x0102 hybrid-ees443ep2 -- Using NTRUEncrypt parameter set ntrueess443ep2
+
+ 0x0103 hybrid-newhope -- Using the New Hope R-LWE scheme
+
+ DEPENDENCY:
+ Proposal 249: Allow CREATE cells with >505 bytes of handshake data
+
+
+
+8. Bibliography
+
+[Zav12] G.M. Zaverucha. Hybrid encryption in the multi-user setting.
+ Cryptology ePrint Archive, Report 2012/159, 2012.
+ http://eprint.iacr.org/2012/159.
+[SWZ16] Schanck, J., Whyte, W., and Z. Zhang, "Circuit extension handshakes
+ for Tor achieving forward secrecy in a quantum world", PETS 2016,
+ DOI 10.1515/popets-2016-0037, June 2016.
+[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti,
+ "HMAC: Keyed-Hashing for Message Authentication",
+ RFC 2104, DOI 10.17487/RFC2104, February 1997
+[RFC5869] Krawczyk, H. and P. Eronen,
+ "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)",
+ RFC 5869, DOI 10.17487/RFC5869, May 2010
+
diff --git a/proposals/proposal-status.txt b/proposals/proposal-status.txt
index 737fa6f..088ce54 100644
--- a/proposals/proposal-status.txt
+++ b/proposals/proposal-status.txt
@@ -437,3 +437,8 @@ again to remind me!
various types of padding between clients and relays, for use in defending
against both website traffic fingerprinting as well as hidden service
circuit setup fingerprinting. (9/2015)
+
+269 Transitionally secure hybrid handshakes [DRAFT]
+
+ Describes a generalised protocol for composing X25519 key exchanges with
+ post-quantum ones.
More information about the tor-commits
mailing list