[tor-commits] [obfsproxy/master] Move the obfs2 specification and threat model to doc/obfs2/.
nickm at torproject.org
nickm at torproject.org
Fri Jan 13 15:09:46 UTC 2012
commit ba1fe6d23905cdaa4536ce17128c1e2dc90dbe5d
Author: George Kadianakis <desnacked at riseup.net>
Date: Thu Jan 12 15:29:17 2012 +0200
Move the obfs2 specification and threat model to doc/obfs2/.
---
doc/obfs2/protocol-spec.txt | 103 +++++++++++++++++++++++++++++++++++++++++++
doc/obfs2/threat-model.txt | 81 +++++++++++++++++++++++++++++++++
doc/obfs2_threat_model.txt | 81 ---------------------------------
doc/protocol-spec.txt | 103 -------------------------------------------
4 files changed, 184 insertions(+), 184 deletions(-)
diff --git a/doc/obfs2/protocol-spec.txt b/doc/obfs2/protocol-spec.txt
new file mode 100644
index 0000000..c0b0578
--- /dev/null
+++ b/doc/obfs2/protocol-spec.txt
@@ -0,0 +1,103 @@
+ obfs2 (The Twobfuscator)
+
+0. Protocol overview
+
+ This is a protocol obfuscation layer for TCP protocols. Its purpose
+ is to keep a third party from telling what protocol is in use based
+ on message contents. It is based on brl's ssh obfuscation protocol.
+
+ It does not provide authentication or data integrity. It does not
+ hide data lengths. It is more suitable for providing a layer of
+ obfuscation for an existing authenticated protocol, like SSH or TLS.
+
+ The protocol has two phases: in the first phase, the parties
+ establish keys. In the second, the parties exchange superenciphered
+ traffic.
+
+1. Primitives, notation, and constants.
+
+ H(x) is SHA256 of x.
+ H^n(x) is H(x) called iteratively n times.
+
+ E(K,s) is the AES-CTR-128 encryption of s using K as key.
+
+ x | y is the concatenation of x and y.
+ UINT32(n) is the 4 byte value of n in big-endian (network) order.
+ SR(n) is n bytes of strong random data.
+ WR(n) is n bytes of weaker random data.
+ "xyz" is the ASCII characters 'x', 'y', and 'z', not NUL-terminated.
+ s[:n] is the first n bytes of s.
+ s[n:] is the last n bytes of s.
+
+ MAGIC_VALUE is 0x2BF5CA7E
+ SEED_LENGTH is 16
+ MAX_PADDING is 8192
+ HASH_ITERATIONS is 100000
+
+ KEYLEN is the length of the key used by E(K,s) -- that is, 16.
+ IVLEN is the length of the IV used by E(K,s) -- that is, 16.
+
+ HASHLEN is the length of the output of H() -- that is, 32.
+
+ MAC(s, x) = H(s | x | s)
+
+ A "byte" is an 8-bit octet.
+
+ We require that HASHLEN >= KEYLEN + IVLEN
+
+2. Key establishment phase.
+
+ The party who opens the connection is the 'initiator'; the one who
+ accepts it is the 'responder'. Each begins by generating a seed
+ and a padding key as follows. The initiator generates:
+
+ INIT_SEED = SR(SEED_LENGTH)
+ INIT_PAD_KEY = MAC("Initiator obfuscation padding", INIT_SEED)[:KEYLEN]
+
+ And the responder generates:
+
+ RESP_SEED = SR(SEED_LENGTH)
+ RESP_PAD_KEY = MAC("Responder obfuscation padding", INIT_SEED)[:KEYLEN]
+
+ Each then generates a random number PADLEN in range from 0 through
+ MAX_PADDING (inclusive).
+
+ The initiator then sends:
+
+ INIT_SEED | E(INIT_PAD_KEY, UINT32(MAGIC_VALUE) | UINT32(PADLEN) | WR(PADLEN))
+
+ and the responder sends:
+
+ RESP_SEED | E(RESP_PAD_KEY, UINT32(MAGIC_VALUE) | UINT32(PADLEN) | WR(PADLEN))
+
+ Upon receiving the SEED from the other party, each party derives
+ the other party's padding key value as above, and decrypts the next
+ 8 bytes of the key establishment message. If the MAGIC_VALUE does
+ not match, or the PADLEN value is greater than MAX_PADDING, the
+ party receiving it should close the connection immediately.
+ Otherwise, it should read the remaining PADLEN bytes of padding data
+ and discard them.
+
+ Additional keys are then derived as:
+
+ INIT_SECRET = MAC("Initiator obfuscated data", INIT_SEED|RESP_SEED)
+ RESP_SECRET = MAC("Responder obfuscated data", INIT_SEED|RESP_SEED)
+ INIT_KEY = INIT_SECRET[:KEYLEN]
+ INIT_IV = INIT_SECRET[KEYLEN:]
+ RESP_KEY = RESP_SECRET[:KEYLEN]
+ RESP_IV = RESP_SECRET[KEYLEN:]
+
+ The INIT_KEY value keys a stream cipher used to encrypt values from
+ initiator to responder thereafter. The stream cipher's IV is
+ INIT_IV. The RESP_KEY value keys a stream cipher used to encrypt
+ values from responder to initiator thereafter. That stream cipher's
+ IV is RESP_IV.
+
+3. Shared-secret extension
+
+ Optionally, if the client and server share a secret value SECRET,
+ they can replace the MAC function with:
+
+ MAC(s,x) = H^n(s | x | H(SECRET) | s)
+
+ where n = HASH_ITERATIONS.
diff --git a/doc/obfs2/threat-model.txt b/doc/obfs2/threat-model.txt
new file mode 100644
index 0000000..c13da2c
--- /dev/null
+++ b/doc/obfs2/threat-model.txt
@@ -0,0 +1,81 @@
+ Threat model for the obfs2 obfuscation protocol
+
+ George Kadianakis
+ Nick Mathewson
+
+0. Abstract
+
+ We discuss the intended threat model for the 'obfs2' protocol
+ obfuscator, its limitations, and its implications for the protocol
+ design.
+
+ The 'obfs2' protocol is based on Bruce Leidl's obfuscated SSH layer,
+ and is documented in the 'doc/protocol-spec.txt' file in the obfsproxy
+ distribution.
+
+1. Adversary capabilities and non-capabilities
+
+ We assume a censor with limited per-connection resources.
+
+ The adversary controls the infrastructure of the network within and
+ at the edges of her jurisdiction, and she can potentially monitor,
+ block, alter, and inject trafï¬c anywhere within this region.
+
+ However, the adversary's computational resources are limited.
+ Specifically, the adversary does not have the resources in her
+ censorship infrastructure to store very much long-term information
+ about any given IP or connection.
+
+ The adversary also holds a blacklist of network protocols, which she
+ is interested in blocking. We assume that the adversary does not have
+ a complete list of specific IPs running that protocol, though
+ preventing this is out-of-scope.
+
+2. The adversary's goals
+
+ The censor wants to ban particular encrypted protocols or
+ applications, and is willing to tolerate some collateral damage, but
+ is not willing to ban all encrypted traffic entirely.
+
+3. Goals of obfs2
+
+ Currently, most attackers in the category described above implement
+ their censorship by one or more firewalls that looking for protocol
+ signatures and block protocols matching those signatures. These
+ signatures are typically in the form of static strings to be matched
+ or regular expressions to be evaluated, over a packet or TCP flow.
+
+ obfs2 attempts to counter the above attack by removing content
+ signatures from network traffic. obfs2 encrypts the traffic stream
+ with a stream cipher, which results in the traffic looking uniformly
+ random.
+
+4. Non-goals of obfs2
+
+ obfs2 was designed as a proof-of-concept for Tor's pluggable
+ transport system: it is simple, useable and easily implementable. It
+ does _not_ try to protect against more sophisticated adversaries.
+
+ obfs2 does not try to protect against non-content protocol
+ fingerprints, like the packet size or timing.
+
+ obfs2 does not try to protect against attackers capable of measuring
+ traffic entropy.
+
+ obfs2 (in its default configuration) does not try to protect against
+ Deep Packet Inspection machines that expect the obfs2 protocol and
+ have the resources to run it. Such machines can trivially retrieve
+ the decryption key off the traffic stream and use it to decrypt obfs2
+ and detect the Tor protocol.
+
+ obfs2 assumes that the underlying protocol provides (or does not
+ need!) integrity, confidentiality, and authentication; it provides
+ none of those on its own.
+
+ In other words, obfs2 does not try to protect against anything other
+ than fingerprintable TLS content patterns.
+
+ That said, obfs2 is not useless. It protects against many real-life
+ Tor traffic detection methods currentl deployed, since most of them
+ currently use static SSL handshake strings as signatures.
+
diff --git a/doc/obfs2_threat_model.txt b/doc/obfs2_threat_model.txt
deleted file mode 100644
index c13da2c..0000000
--- a/doc/obfs2_threat_model.txt
+++ /dev/null
@@ -1,81 +0,0 @@
- Threat model for the obfs2 obfuscation protocol
-
- George Kadianakis
- Nick Mathewson
-
-0. Abstract
-
- We discuss the intended threat model for the 'obfs2' protocol
- obfuscator, its limitations, and its implications for the protocol
- design.
-
- The 'obfs2' protocol is based on Bruce Leidl's obfuscated SSH layer,
- and is documented in the 'doc/protocol-spec.txt' file in the obfsproxy
- distribution.
-
-1. Adversary capabilities and non-capabilities
-
- We assume a censor with limited per-connection resources.
-
- The adversary controls the infrastructure of the network within and
- at the edges of her jurisdiction, and she can potentially monitor,
- block, alter, and inject trafï¬c anywhere within this region.
-
- However, the adversary's computational resources are limited.
- Specifically, the adversary does not have the resources in her
- censorship infrastructure to store very much long-term information
- about any given IP or connection.
-
- The adversary also holds a blacklist of network protocols, which she
- is interested in blocking. We assume that the adversary does not have
- a complete list of specific IPs running that protocol, though
- preventing this is out-of-scope.
-
-2. The adversary's goals
-
- The censor wants to ban particular encrypted protocols or
- applications, and is willing to tolerate some collateral damage, but
- is not willing to ban all encrypted traffic entirely.
-
-3. Goals of obfs2
-
- Currently, most attackers in the category described above implement
- their censorship by one or more firewalls that looking for protocol
- signatures and block protocols matching those signatures. These
- signatures are typically in the form of static strings to be matched
- or regular expressions to be evaluated, over a packet or TCP flow.
-
- obfs2 attempts to counter the above attack by removing content
- signatures from network traffic. obfs2 encrypts the traffic stream
- with a stream cipher, which results in the traffic looking uniformly
- random.
-
-4. Non-goals of obfs2
-
- obfs2 was designed as a proof-of-concept for Tor's pluggable
- transport system: it is simple, useable and easily implementable. It
- does _not_ try to protect against more sophisticated adversaries.
-
- obfs2 does not try to protect against non-content protocol
- fingerprints, like the packet size or timing.
-
- obfs2 does not try to protect against attackers capable of measuring
- traffic entropy.
-
- obfs2 (in its default configuration) does not try to protect against
- Deep Packet Inspection machines that expect the obfs2 protocol and
- have the resources to run it. Such machines can trivially retrieve
- the decryption key off the traffic stream and use it to decrypt obfs2
- and detect the Tor protocol.
-
- obfs2 assumes that the underlying protocol provides (or does not
- need!) integrity, confidentiality, and authentication; it provides
- none of those on its own.
-
- In other words, obfs2 does not try to protect against anything other
- than fingerprintable TLS content patterns.
-
- That said, obfs2 is not useless. It protects against many real-life
- Tor traffic detection methods currentl deployed, since most of them
- currently use static SSL handshake strings as signatures.
-
diff --git a/doc/protocol-spec.txt b/doc/protocol-spec.txt
deleted file mode 100644
index c0b0578..0000000
--- a/doc/protocol-spec.txt
+++ /dev/null
@@ -1,103 +0,0 @@
- obfs2 (The Twobfuscator)
-
-0. Protocol overview
-
- This is a protocol obfuscation layer for TCP protocols. Its purpose
- is to keep a third party from telling what protocol is in use based
- on message contents. It is based on brl's ssh obfuscation protocol.
-
- It does not provide authentication or data integrity. It does not
- hide data lengths. It is more suitable for providing a layer of
- obfuscation for an existing authenticated protocol, like SSH or TLS.
-
- The protocol has two phases: in the first phase, the parties
- establish keys. In the second, the parties exchange superenciphered
- traffic.
-
-1. Primitives, notation, and constants.
-
- H(x) is SHA256 of x.
- H^n(x) is H(x) called iteratively n times.
-
- E(K,s) is the AES-CTR-128 encryption of s using K as key.
-
- x | y is the concatenation of x and y.
- UINT32(n) is the 4 byte value of n in big-endian (network) order.
- SR(n) is n bytes of strong random data.
- WR(n) is n bytes of weaker random data.
- "xyz" is the ASCII characters 'x', 'y', and 'z', not NUL-terminated.
- s[:n] is the first n bytes of s.
- s[n:] is the last n bytes of s.
-
- MAGIC_VALUE is 0x2BF5CA7E
- SEED_LENGTH is 16
- MAX_PADDING is 8192
- HASH_ITERATIONS is 100000
-
- KEYLEN is the length of the key used by E(K,s) -- that is, 16.
- IVLEN is the length of the IV used by E(K,s) -- that is, 16.
-
- HASHLEN is the length of the output of H() -- that is, 32.
-
- MAC(s, x) = H(s | x | s)
-
- A "byte" is an 8-bit octet.
-
- We require that HASHLEN >= KEYLEN + IVLEN
-
-2. Key establishment phase.
-
- The party who opens the connection is the 'initiator'; the one who
- accepts it is the 'responder'. Each begins by generating a seed
- and a padding key as follows. The initiator generates:
-
- INIT_SEED = SR(SEED_LENGTH)
- INIT_PAD_KEY = MAC("Initiator obfuscation padding", INIT_SEED)[:KEYLEN]
-
- And the responder generates:
-
- RESP_SEED = SR(SEED_LENGTH)
- RESP_PAD_KEY = MAC("Responder obfuscation padding", INIT_SEED)[:KEYLEN]
-
- Each then generates a random number PADLEN in range from 0 through
- MAX_PADDING (inclusive).
-
- The initiator then sends:
-
- INIT_SEED | E(INIT_PAD_KEY, UINT32(MAGIC_VALUE) | UINT32(PADLEN) | WR(PADLEN))
-
- and the responder sends:
-
- RESP_SEED | E(RESP_PAD_KEY, UINT32(MAGIC_VALUE) | UINT32(PADLEN) | WR(PADLEN))
-
- Upon receiving the SEED from the other party, each party derives
- the other party's padding key value as above, and decrypts the next
- 8 bytes of the key establishment message. If the MAGIC_VALUE does
- not match, or the PADLEN value is greater than MAX_PADDING, the
- party receiving it should close the connection immediately.
- Otherwise, it should read the remaining PADLEN bytes of padding data
- and discard them.
-
- Additional keys are then derived as:
-
- INIT_SECRET = MAC("Initiator obfuscated data", INIT_SEED|RESP_SEED)
- RESP_SECRET = MAC("Responder obfuscated data", INIT_SEED|RESP_SEED)
- INIT_KEY = INIT_SECRET[:KEYLEN]
- INIT_IV = INIT_SECRET[KEYLEN:]
- RESP_KEY = RESP_SECRET[:KEYLEN]
- RESP_IV = RESP_SECRET[KEYLEN:]
-
- The INIT_KEY value keys a stream cipher used to encrypt values from
- initiator to responder thereafter. The stream cipher's IV is
- INIT_IV. The RESP_KEY value keys a stream cipher used to encrypt
- values from responder to initiator thereafter. That stream cipher's
- IV is RESP_IV.
-
-3. Shared-secret extension
-
- Optionally, if the client and server share a secret value SECRET,
- they can replace the MAC function with:
-
- MAC(s,x) = H^n(s | x | H(SECRET) | s)
-
- where n = HASH_ITERATIONS.
More information about the tor-commits
mailing list