From 08efb61c55437a286f582c23ae3748789e8d3d2f Mon Sep 17 00:00:00 2001 From: Max Lv Date: Fri, 24 Feb 2017 13:00:00 +0800 Subject: [PATCH] Update docs for #28 --- en/about/contributors.html | 2 +- en/config/advanced.html | 2 +- en/config/quick-guide.html | 2 +- en/download/clients.html | 2 +- en/download/servers.html | 2 +- en/index.html | 2 +- en/sitemap.xml | 24 +++++++++++++++--------- en/spec/AEAD-Ciphers.html | 2 +- en/spec/Plugin.html | 9 +++++++++ en/spec/Protocol.html | 2 +- en/spec/Stream-Ciphers.html | 2 +- src/content/en/spec | 2 +- 12 files changed, 34 insertions(+), 19 deletions(-) create mode 100644 en/spec/Plugin.html diff --git a/en/about/contributors.html b/en/about/contributors.html index 6cc8cda0..08a79b06 100644 --- a/en/about/contributors.html +++ b/en/about/contributors.html @@ -1 +1 @@ -Shadowsocks - Contributors

Contributors

Core Contributors

@clowwindy

The creator of shadowsocks and the maintainer of shadowsocks-python/nodejs/gui/iOS.

@cyfdecyf

The maintainer of shadowsocks-go and cow.

@madeye

The maintainer of shadowsocks-libev/android and this project site.

@linusyang

The maintainer of shadowsocks-libev and MobileShadowSocks.

@aa65535

The maintainer of openwrt-shadowsocks.

@librehat

The maintainer of shadowsocks-qt5 and libQtShadowsocks

Other Contributors

@ohdarling

The maintainer of GoAgentX.

@fqrouter

The maintainer of fqrouter.

\ No newline at end of file +Shadowsocks - Contributors

Contributors

Core Contributors

@clowwindy

The creator of shadowsocks and the maintainer of shadowsocks-python/nodejs/gui/iOS.

@cyfdecyf

The maintainer of shadowsocks-go and cow.

@madeye

The maintainer of shadowsocks-libev/android and this project site.

@linusyang

The maintainer of shadowsocks-libev and MobileShadowSocks.

@aa65535

The maintainer of openwrt-shadowsocks.

@librehat

The maintainer of shadowsocks-qt5 and libQtShadowsocks

Other Contributors

@ohdarling

The maintainer of GoAgentX.

@fqrouter

The maintainer of fqrouter.

\ No newline at end of file diff --git a/en/config/advanced.html b/en/config/advanced.html index faade990..0760caac 100644 --- a/en/config/advanced.html +++ b/en/config/advanced.html @@ -1,4 +1,4 @@ -Shadowsocks - Advanced

Advanced

Optimize the shadowsocks server on Linux

First of all, upgrade your Linux kernel to 3.5 or later.

Step 1, increase the maximum number of open file descriptors

To handle thousands of concurrent TCP connections, we should increase the limit of file descriptors opened.

Edit the limits.conf

vi /etc/security/limits.conf

Add these two lines

* soft nofile 51200
+Shadowsocks - Advanced
Advanced
Optimize the shadowsocks server on Linux
First of all, upgrade your Linux kernel to 3.5 or later.
Step 1, increase the maximum number of open file descriptors
To handle thousands of concurrent TCP connections, we should increase the limit of file descriptors opened.
Edit the limits.conf
vi /etc/security/limits.conf
Add these two lines
* soft nofile 51200
 * hard nofile 51200
Then, before you start the shadowsocks server, set the ulimit first
ulimit -n 51200
Step 2, Tune the kernel parameters
The priciples of tuning parameters for shadowsocks are
  1. Reuse ports and conections as soon as possible.
  2. Enlarge the queues and buffers as large as possible.
  3. Choose the TCP congestion algorithm for large latency and high throughput.
Here is an example /etc/sysctl.conf of our production servers:
fs.file-max = 51200
 
 net.core.rmem_max = 67108864
diff --git a/en/config/quick-guide.html b/en/config/quick-guide.html
index a8ff02ab..99bf0a05 100644
--- a/en/config/quick-guide.html
+++ b/en/config/quick-guide.html
@@ -1,4 +1,4 @@
-Shadowsocks - Quick Guide
Quick Guide
Config File
Shadowsocks accepts JSON format configs like this:
{
+Shadowsocks - Quick Guide
Quick Guide
Config File
Shadowsocks accepts JSON format configs like this:
{
     "server":"my_server_ip",
     "server_port":8388,
     "local_port":1080,
diff --git a/en/download/clients.html b/en/download/clients.html
index 3eb2ea14..121e41b8 100644
--- a/en/download/clients.html
+++ b/en/download/clients.html
@@ -1 +1 @@
-Shadowsocks - Clients
Clients

   Windows
GUI Client
Command-line Client
  • pip install shadowsocks
   Mac OS X
GUI Client
Command-line Client
  • pip install shadowsocks
  • brew install shadowsocks-libev
  • cpan Net::Shadowsocks
   Linux
GUI Client
Command-line Client
  • pip install shadowsocks
  • apt-get install shadowsocks-libev
  • cpan Net::Shadowsocks
   Android
   iOS
   OpenWRT
  • shadowsocks-libev
    • opkg install shadowsocks-libev
  • shadowsocks-libev-polarssl
    • opkg install shadowsocks-libev-polarssl
Next Step
Ready to use? Just navigate to Quick Guide.
Or plan to deploy your own server? See Servers.
Have a Minute?
Take one minute to complete a survey about shadowsocks user base. It's totally anonymous and no login required.

\ No newline at end of file
+Shadowsocks - Clients
Clients

   Windows
GUI Client
Command-line Client
  • pip install shadowsocks
   Mac OS X
GUI Client
Command-line Client
  • pip install shadowsocks
  • brew install shadowsocks-libev
  • cpan Net::Shadowsocks
   Linux
GUI Client
Command-line Client
  • pip install shadowsocks
  • apt-get install shadowsocks-libev
  • cpan Net::Shadowsocks
   Android
   iOS
   OpenWRT
  • shadowsocks-libev
    • opkg install shadowsocks-libev
  • shadowsocks-libev-polarssl
    • opkg install shadowsocks-libev-polarssl
Next Step
Ready to use? Just navigate to Quick Guide.
Or plan to deploy your own server? See Servers.
Have a Minute?
Take one minute to complete a survey about shadowsocks user base. It's totally anonymous and no login required.

\ No newline at end of file
diff --git a/en/download/servers.html b/en/download/servers.html
index a79cdc76..6171eddd 100644
--- a/en/download/servers.html
+++ b/en/download/servers.html
@@ -1,4 +1,4 @@
-Shadowsocks - Servers
Servers
Python
shadowsocks-python is the initial version written by @clowwindy. It aims to provide a simple-to-use and easy-to-deploy implementation with basic features of shadowsocks.
PyPI
First, make sure you have Python 2.6 or 2.7.
$ python --version
+Shadowsocks - Servers
Servers
Python
shadowsocks-python is the initial version written by @clowwindy. It aims to provide a simple-to-use and easy-to-deploy implementation with basic features of shadowsocks.
PyPI
First, make sure you have Python 2.6 or 2.7.
$ python --version
 Python 2.6.8
Then install from PIP
$ pip install shadowsocks
GitHub
Checkout the source codes and run the scripts directly.
$ git clone https://github.com/shadowsocks/shadowsocks.git
 $ cd shadowsocks
 $ python setup.py
shadowsocks-python is licensed under the Apache License, Version 2.0.
Go
shadowsocks-go is a state-of-the-art port written in Go language, designed for large-scale system. It implements the multi-ports-multi-password feature, which is suitable for paid service providers with user management and traffic statistics support. This port is maintained by @cyfdecyf.
Pre-built Binaries
Download archives from http://dl.chenyufei.info/shadowsocks/.
GitHub
Use go get to install the scripts.
$ go get github.com/shadowsocks/shadowsocks-go/cmd/shadowsocks-server
shadowsocks-go is licensed under the MIT license.
C with libev
shadowsocks-libev is a lightweight and full featured port for embedded devices and low end boxes. It's a pure C implementation and has a very small footprint (several megabytes) for thousands of connections. This port is maintained by @madeye.
Debian/Ubuntu:
Shadowsocks-libev is available in the official repository for Debian 9("Stretch"), unstable, Ubuntu 16.10 and later derivatives:
sudo apt update
diff --git a/en/index.html b/en/index.html
index c0236a7f..a69198f2 100644
--- a/en/index.html
+++ b/en/index.html
@@ -1 +1 @@
-Shadowsocks - A secure socks5 proxy
A secure socks5 proxy,
designed to protect your Internet traffic.
  Try it now!  Get support
If you want to keep a secret, you must also hide it from yourself.
  • Super Fast
    Bleeding edge techniques using Asynchronous I/O and Event-driven programming.
  • Flexible Encryption
    Secured with industry level encryption algorithm. Flexible to support custom algorithms.
  • Mobile Ready
    Optimized for mobile device and wireless network, without any keep-alive connections.
  • Cross Platform
    Available on most platforms, including Windows, Linux, Mac, Android, iOS, and OpenWRT.
  • Open Source
    Totally free and open source. A worldwide community devoted to deliver bug-free code and long-term support.
  • Easy Deployment
    Easy deployment with pip, aur, freshports and many other package manager systems.

\ No newline at end of file
+Shadowsocks - A secure socks5 proxy
A secure socks5 proxy,
designed to protect your Internet traffic.
  Try it now!  Get support
If you want to keep a secret, you must also hide it from yourself.
  • Super Fast
    Bleeding edge techniques using Asynchronous I/O and Event-driven programming.
  • Flexible Encryption
    Secured with industry level encryption algorithm. Flexible to support custom algorithms.
  • Mobile Ready
    Optimized for mobile device and wireless network, without any keep-alive connections.
  • Cross Platform
    Available on most platforms, including Windows, Linux, Mac, Android, iOS, and OpenWRT.
  • Open Source
    Totally free and open source. A worldwide community devoted to deliver bug-free code and long-term support.
  • Easy Deployment
    Easy deployment with pip, aur, freshports and many other package manager systems.

\ No newline at end of file
diff --git a/en/sitemap.xml b/en/sitemap.xml
index 22bcbf5b..613312c0 100644
--- a/en/sitemap.xml
+++ b/en/sitemap.xml
@@ -2,55 +2,61 @@
 
   
     http://shadowsocks.org/en/about/contributors.html
-    2017-02-22T04:42:05.952Z
+    2017-02-24T04:59:07.110Z
     daily
     0.5
   
   
     http://shadowsocks.org/en/config/advanced.html
-    2017-02-22T04:42:05.958Z
+    2017-02-24T04:59:07.118Z
     daily
     0.5
   
   
     http://shadowsocks.org/en/config/quick-guide.html
-    2017-02-22T04:42:05.968Z
+    2017-02-24T04:59:07.127Z
     daily
     0.5
   
   
     http://shadowsocks.org/en/download/clients.html
-    2017-02-22T04:42:05.975Z
+    2017-02-24T04:59:07.135Z
     daily
     0.5
   
   
     http://shadowsocks.org/en/download/servers.html
-    2017-02-22T04:42:05.980Z
+    2017-02-24T04:59:07.139Z
     daily
     0.5
   
   
     http://shadowsocks.org/en/
-    2017-02-22T04:42:05.984Z
+    2017-02-24T04:59:07.143Z
     daily
     0.5
   
   
     http://shadowsocks.org/en/spec/AEAD-Ciphers.html
-    2017-02-22T04:42:05.988Z
+    2017-02-24T04:59:07.149Z
+    daily
+    0.5
+  
+  
+    http://shadowsocks.org/en/spec/Plugin.html
+    2017-02-24T04:59:07.161Z
     daily
     0.5
   
   
     http://shadowsocks.org/en/spec/Protocol.html
-    2017-02-22T04:42:05.991Z
+    2017-02-24T04:59:07.165Z
     daily
     0.5
   
   
     http://shadowsocks.org/en/spec/Stream-Ciphers.html
-    2017-02-22T04:42:05.995Z
+    2017-02-24T04:59:07.172Z
     daily
     0.5
   
diff --git a/en/spec/AEAD-Ciphers.html b/en/spec/AEAD-Ciphers.html
index 9b2c4fa4..78fb3c47 100644
--- a/en/spec/AEAD-Ciphers.html
+++ b/en/spec/AEAD-Ciphers.html
@@ -1 +1 @@
-Shadowsocks - AEAD Ciphers
AEAD Ciphers
AEAD stands for Authenticated Encryption with Associated Data. Currently we do not have any Associated Data, so effectively we are using Authenticated Encryption only. AEAD ciphers simultaneously provide confidentiality, integrity, and authenticity. They offer excellent performance and power efficiency on modern hardware. Users are recommended to use the following AEAD ciphers whenever possible.
NameKey SizeSalt SizeNonce SizeTag Size
xchacha20-ietf-poly130532322416
chacha20-ietf-poly130532321216
aes-256-gcm32321216
aes-192-gcm24241216
aes-128-gcm16161216
The way Shadowsocks using AEAD ciphers is specified in SIP004 and amended in SIP007. SIP004 was proposed by @Mygod with design inspirations from @wongsyrone, @Noisyfox and @breakwa11. SIP007 was proposed by @riobard with input from @madeye, @Mygod, @wongsyrone, and many others.
Key Derivation
HKDF_SHA1 is a function that takes a secret key, a non-secret salt, an info string, and produces a subkey that is cryptographically strong even if the input secret key is weak.
HKDF_SHA1(key, salt, info) => subkey
The info string binds the generated subkey to a specific application context. In our case, it must be the string "ss-subkey" without quotes.
We derive a per-session subkey from a pre-shared master key using HKDF_SHA1. Salt must be unique through the entire life of the pre-shared master key.
Authenticated Encryption/Decryption
AE_encrypt is a function that takes a secret key, a non-secret nonce, a message, and produces ciphertext and authentication tag. Nonce must be unique for a given key in each invocation.
AE_encrypt(key, nonce, message) => (ciphertext, tag)
AE_decrypt is a function that takes a secret key, non-secret nonce, ciphertext, authentication tag, and produces original message. If any of the input is tampered with, decryption will fail.
AE_decrypt(key, nonce, ciphertext, tag) => message
TCP
An AEAD encrypted TCP stream starts with a randomly generated salt to derive the per-session subkey, followed by any number of encrypted chunks. Each chunk has the following structure:
[encrypted payload length][length tag][encrypted payload][payload tag]
Payload length is a 2-byte big-endian unsigned integer capped at 0x3FFF. The higher two bits are reserved and must be set to zero. Payload is therefore limited to 16*1024 - 1 bytes.
The first AEAD encrypt/decrypt operation uses a counting nonce starting from 0. After each encrypt/decrypt operation, the nonce is incremented by one as if it were an unsigned little-endian integer. Note that each TCP chunk involves two AEAD encrypt/decrypt operation: one for the payload length, and one for the payload. Therefore each chunk increases the nonce twice.
UDP
An AEAD encrypted UDP packet has the following structure
[salt][encrypted payload][tag]
The salt is used to derive the per-session subkey and must be generated randomly to ensure uniqueness. Each UDP packet is encrypted/decrypted independently, using the derived subkey and a nonce with all zero bytes.

\ No newline at end of file
+Shadowsocks - AEAD Ciphers
AEAD Ciphers
AEAD stands for Authenticated Encryption with Associated Data. Currently we do not have any Associated Data, so effectively we are using Authenticated Encryption only. AEAD ciphers simultaneously provide confidentiality, integrity, and authenticity. They offer excellent performance and power efficiency on modern hardware. Users are recommended to use the following AEAD ciphers whenever possible.
NameKey SizeSalt SizeNonce SizeTag Size
xchacha20-ietf-poly130532322416
chacha20-ietf-poly130532321216
aes-256-gcm32321216
aes-192-gcm24241216
aes-128-gcm16161216
The way Shadowsocks using AEAD ciphers is specified in SIP004 and amended in SIP007. SIP004 was proposed by @Mygod with design inspirations from @wongsyrone, @Noisyfox and @breakwa11. SIP007 was proposed by @riobard with input from @madeye, @Mygod, @wongsyrone, and many others.
Key Derivation
HKDF_SHA1 is a function that takes a secret key, a non-secret salt, an info string, and produces a subkey that is cryptographically strong even if the input secret key is weak.
HKDF_SHA1(key, salt, info) => subkey
The info string binds the generated subkey to a specific application context. In our case, it must be the string "ss-subkey" without quotes.
We derive a per-session subkey from a pre-shared master key using HKDF_SHA1. Salt must be unique through the entire life of the pre-shared master key.
Authenticated Encryption/Decryption
AE_encrypt is a function that takes a secret key, a non-secret nonce, a message, and produces ciphertext and authentication tag. Nonce must be unique for a given key in each invocation.
AE_encrypt(key, nonce, message) => (ciphertext, tag)
AE_decrypt is a function that takes a secret key, non-secret nonce, ciphertext, authentication tag, and produces original message. If any of the input is tampered with, decryption will fail.
AE_decrypt(key, nonce, ciphertext, tag) => message
TCP
An AEAD encrypted TCP stream starts with a randomly generated salt to derive the per-session subkey, followed by any number of encrypted chunks. Each chunk has the following structure:
[encrypted payload length][length tag][encrypted payload][payload tag]
Payload length is a 2-byte big-endian unsigned integer capped at 0x3FFF. The higher two bits are reserved and must be set to zero. Payload is therefore limited to 16*1024 - 1 bytes.
The first AEAD encrypt/decrypt operation uses a counting nonce starting from 0. After each encrypt/decrypt operation, the nonce is incremented by one as if it were an unsigned little-endian integer. Note that each TCP chunk involves two AEAD encrypt/decrypt operation: one for the payload length, and one for the payload. Therefore each chunk increases the nonce twice.
UDP
An AEAD encrypted UDP packet has the following structure
[salt][encrypted payload][tag]
The salt is used to derive the per-session subkey and must be generated randomly to ensure uniqueness. Each UDP packet is encrypted/decrypted independently, using the derived subkey and a nonce with all zero bytes.

\ No newline at end of file
diff --git a/en/spec/Plugin.html b/en/spec/Plugin.html
new file mode 100644
index 00000000..385b1392
--- /dev/null
+++ b/en/spec/Plugin.html
@@ -0,0 +1,9 @@
+Shadowsocks - Plugin
Plugin
SIP003: A simplified plugin design for shadowsocks
Architecture Overview
The plugin of shadowsocks is very similar to the Pluggable Transport plugins from Tor project. Dislike the SOCKS5 proxy design in PT, every SIP003 plugin works as a tunnel (or called local port forwarding). This design aims to avoid per-connection arguments in PT, leading to much easier implementation.
     +------------+                    +---------------------------+
+     |  SS Client +-- Local Loopback --+  Plugin Client (Tunnel)   +--+
+     +------------+                    +---------------------------+  |
+                                                                      |
+                 Public Internet (Obfuscated/Transformed traffic) ==> |
+                                                                      |
+     +------------+                    +---------------------------+  |
+     |  SS Server +-- Local Loopback --+  Plugin Server (Tunnel)   +--+
+     +------------+                    +---------------------------+
Life cycle of a plugin
Very similar to PT, the plugin client/server is started as child process of shadowsocks client/server.
If any error happens, the child process of plugin should exit with a error code. Then, the parent process of shadowsocks stops as well (SIGCHLD).
When a shadowsocks client/server is stopped by user, the child process of plugin will also be terminated.
Passing arguments to a plugin
A plugin accepts arguments through environment variables.
a. Four MUST-HAVE environment variables are SS_REMOTE_HOST, SS_REMOTE_PORT, SS_LOCAL_HOST and SS_LOCAL_PORT. SS_REMOTE_HOST and SS_REMOTE_PORT are the hostname and port of the remote plugin service. SS_LOCAL_HOST and SS_LOCAL_PORT are the hostname and port of the local shadowsocks or plugin service.
b. One OPTIONAL environment variable is SS_PLUGIN_OPTIONS. If a plugin requires additional arguments, like path to a config file, these arguments can be passed as extra options in a formatted string. An example is 'obfs=http;obfs-host=www.baidu.com', where semicolons, equal signs and backslashes MUST be escaped with a backslash.
Compatibility with PT
For all the plugins from Tor projects, there are two possible ways to support them. 1) We can fork these plugins and modify them to support SIP003, e.g. obfs4-tunnel. 2) Implement a adapter of PT as SIP003 plugin.
Licenses of plugins
As all plugin services should run in a separate process, they can pick any license they like. There is no GPL restrictions for any plugin providers.
Restrictions
a. Plugin over plugin is NOT supported. Only one plugin can be enabled when a shadowsocks service is started. If you really need this feature, implement a plugin-over-plugin transport as a SIP003 plugin. b. Only TCP traffic is forwarded. For now, there is no plan to support UDP traffic forwarding.
Example projects
Command line example
On the server:
ss-server --plugin obfs-server --plugin-opts "obfs=http"
On the client:
ss-local -c config.json --plugin obfs-local --plugin-opts "obfs=http;obfs-host=www.baidu.com"

\ No newline at end of file
diff --git a/en/spec/Protocol.html b/en/spec/Protocol.html
index 6790e264..4901b57f 100644
--- a/en/spec/Protocol.html
+++ b/en/spec/Protocol.html
@@ -1 +1 @@
-Shadowsocks - Protocol
Protocol
Shadowsocks is a secure split proxy loosely based on SOCKS5.
client <---> ss-local <--[encrypted]--> ss-remote <---> target
The Shadowsocks local component (ss-local) acts like a traditional SOCKS5 server and provides proxy service to clients. It encrypts and forwards data streams and packets from the client to the Shadowsocks remote component (ss-remote), which decrypts and forwards to the target. Replies from target are similarly encrypted and relayed by ss-remote back to ss-local, which decrypts and eventually returns to the original client.
Addressing
Addresses used in Shadowsocks follow the SOCKS5 address format:
[1-byte type][variable-length host][2-byte port]
The following address types are defined:
  • 0x01: host is a 4-byte IPv4 address.
  • 0x03: host is a variable length string, starting with a 1-byte length, followed by up to 255-byte domain name.
  • 0x04: host is a 16-byte IPv6 address.
The port number is a 2-byte big-endian unsigned integer.
TCP
ss-local initiates a TCP connection to ss-remote by sending an encrypted data stream starting with the target address followed by payload data. The exact encryption scheme differs depending on the cipher used.
[target address][payload]
ss-remote receives the encrypted data stream, decrypts and parses the leading target address. It then establishes a new TCP connection to the target and forwards payload data to it. ss-remote receives reply from the target, encrypts and forwards it back to the ss-local, until ss-local disconnects.
UDP
ss-local sends an encrypted data packet containing the target address and payload to ss-remote.
[target address][payload]
Upon receving the encrypted packet, ss-remote decrypts and parses the target address. It then sends a new data packet containing only the payload to the target. ss-remote receives data packets back from target and prepends the target address to the payload in each packet, then sends encrypted copies back to ss-local.
[target address][payload]
Essentially, ss-remote is performing Network Address Translation for ss-local.

\ No newline at end of file
+Shadowsocks - Protocol
Protocol
Shadowsocks is a secure split proxy loosely based on SOCKS5.
client <---> ss-local <--[encrypted]--> ss-remote <---> target
The Shadowsocks local component (ss-local) acts like a traditional SOCKS5 server and provides proxy service to clients. It encrypts and forwards data streams and packets from the client to the Shadowsocks remote component (ss-remote), which decrypts and forwards to the target. Replies from target are similarly encrypted and relayed by ss-remote back to ss-local, which decrypts and eventually returns to the original client.
Addressing
Addresses used in Shadowsocks follow the SOCKS5 address format:
[1-byte type][variable-length host][2-byte port]
The following address types are defined:
  • 0x01: host is a 4-byte IPv4 address.
  • 0x03: host is a variable length string, starting with a 1-byte length, followed by up to 255-byte domain name.
  • 0x04: host is a 16-byte IPv6 address.
The port number is a 2-byte big-endian unsigned integer.
TCP
ss-local initiates a TCP connection to ss-remote by sending an encrypted data stream starting with the target address followed by payload data. The exact encryption scheme differs depending on the cipher used.
[target address][payload]
ss-remote receives the encrypted data stream, decrypts and parses the leading target address. It then establishes a new TCP connection to the target and forwards payload data to it. ss-remote receives reply from the target, encrypts and forwards it back to the ss-local, until ss-local disconnects.
UDP
ss-local sends an encrypted data packet containing the target address and payload to ss-remote.
[target address][payload]
Upon receving the encrypted packet, ss-remote decrypts and parses the target address. It then sends a new data packet containing only the payload to the target. ss-remote receives data packets back from target and prepends the target address to the payload in each packet, then sends encrypted copies back to ss-local.
[target address][payload]
Essentially, ss-remote is performing Network Address Translation for ss-local.

\ No newline at end of file
diff --git a/en/spec/Stream-Ciphers.html b/en/spec/Stream-Ciphers.html
index 1a179338..afbaf41d 100644
--- a/en/spec/Stream-Ciphers.html
+++ b/en/spec/Stream-Ciphers.html
@@ -1 +1 @@
-Shadowsocks - Stream Ciphers
Stream Ciphers
Stream ciphers provide only confidentiality. Data integrity and authenticity is not guaranteed. Users should use AEAD ciphers whenever possible.
The following stream ciphers provide reasonable confidentiality.
NameKey SizeIV Length
aes-128-ctr1616
aes-192-ctr2416
aes-256-ctr3216
aes-128-cfb1616
aes-192-cfb2416
aes-256-cfb3216
camellia-128-cfb1616
camellia-192-cfb2416
camellia-256-cfb3216
chacha20-ietf3212
The following stream ciphers have inherent weaknesses (see discussion at #36). DO NOT USE. Implementors are advised to remove them as soon as possible.
NameKey SizeIV Length
bf-cfb168
chacha20328
salsa20328
rc4-md51616
Stream Encryption/Decryption
Stream_encrypt is a function that takes a secret key, an initialization vector, a message, and produces a ciphertext with the same length as the message.
Stream_encrypt(key, IV, message) => ciphertext
Stream_decrypt is a function that takes a secret key, an initializaiton vector, a ciphertext, and produces the original message.
Stream_decrypt(key, IV, ciphertext) => message
TCP
A stream cipher encrypted TCP stream starts with a randomly generated initializaiton vector, followed by encrypted payload data.
[IV][encrypted payload]
UDP
A stream cipher encrypted UDP packet has the following structure
[IV][encrypted payload]
Each UDP packet is encrypted/decrypted independently with a randomly generated initialization vector.

\ No newline at end of file
+Shadowsocks - Stream Ciphers
Stream Ciphers
Stream ciphers provide only confidentiality. Data integrity and authenticity is not guaranteed. Users should use AEAD ciphers whenever possible.
The following stream ciphers provide reasonable confidentiality.
NameKey SizeIV Length
aes-128-ctr1616
aes-192-ctr2416
aes-256-ctr3216
aes-128-cfb1616
aes-192-cfb2416
aes-256-cfb3216
camellia-128-cfb1616
camellia-192-cfb2416
camellia-256-cfb3216
chacha20-ietf3212
The following stream ciphers have inherent weaknesses (see discussion at #36). DO NOT USE. Implementors are advised to remove them as soon as possible.
NameKey SizeIV Length
bf-cfb168
chacha20328
salsa20328
rc4-md51616
Stream Encryption/Decryption
Stream_encrypt is a function that takes a secret key, an initialization vector, a message, and produces a ciphertext with the same length as the message.
Stream_encrypt(key, IV, message) => ciphertext
Stream_decrypt is a function that takes a secret key, an initializaiton vector, a ciphertext, and produces the original message.
Stream_decrypt(key, IV, ciphertext) => message
TCP
A stream cipher encrypted TCP stream starts with a randomly generated initializaiton vector, followed by encrypted payload data.
[IV][encrypted payload]
UDP
A stream cipher encrypted UDP packet has the following structure
[IV][encrypted payload]
Each UDP packet is encrypted/decrypted independently with a randomly generated initialization vector.

\ No newline at end of file
diff --git a/src/content/en/spec b/src/content/en/spec
index 5bce9b31..43d174f1 160000
--- a/src/content/en/spec
+++ b/src/content/en/spec
@@ -1 +1 @@
-Subproject commit 5bce9b31468697c248e0a7bf65105ef63abb2829
+Subproject commit 43d174f10aac0f10ad7c5496a18f08e09589f139