The creator of shadowsocks and the maintainer of shadowsocks-python/nodejs/gui/iOS.
The maintainer of shadowsocks-go and cow.
The maintainer of shadowsocks-libev/android and this project site.
The maintainer of shadowsocks-libev and MobileShadowSocks.
The maintainer of openwrt-shadowsocks.
The maintainer of shadowsocks-qt5 and libQtShadowsocks
The maintainer of GoAgentX.
The maintainer of fqrouter.
The creator of shadowsocks and the maintainer of shadowsocks-python/nodejs/gui/iOS.
The maintainer of shadowsocks-go and cow.
The maintainer of shadowsocks-libev/android and this project site.
The maintainer of shadowsocks-libev and MobileShadowSocks.
The maintainer of openwrt-shadowsocks.
The maintainer of shadowsocks-qt5 and libQtShadowsocks
The maintainer of GoAgentX.
The maintainer of fqrouter.
First of all, upgrade your Linux kernel to 3.5 or later.
To handle thousands of concurrent TCP connections, we should increase the limit of file descriptors opened.
Edit the limits.conf
vi /etc/security/limits.confAdd these two lines
* soft nofile 51200
+Shadowsocks - 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
- Reuse ports and conections as soon as possible.
- Enlarge the queues and buffers as large as possible.
- 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 Config File
Shadowsocks accepts JSON format configs like this:
{
+Shadowsocks - 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
Windows
GUI Client
Command-line Client
pip install shadowsocks
Mac OS X
GUI Client
- ShadowsocksX-NG: GitHub
Command-line Client
pip install shadowsocksbrew install shadowsocks-libevcpan Net::Shadowsocks
Linux
GUI Client
- Shadowsocks-Qt5: GitHub
Command-line Client
pip install shadowsocksapt-get install shadowsocks-libevcpan Net::Shadowsocks
Android
- shadowsocks-android:
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
Windows
GUI Client
Command-line Client
pip install shadowsocks
Mac OS X
GUI Client
- ShadowsocksX-NG: GitHub
Command-line Client
pip install shadowsocksbrew install shadowsocks-libevcpan Net::Shadowsocks
Linux
GUI Client
- Shadowsocks-Qt5: GitHub
Command-line Client
pip install shadowsocksapt-get install shadowsocks-libevcpan Net::Shadowsocks
Android
- shadowsocks-android:
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 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 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.
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.
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 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.
Name Key Size Salt Size Nonce Size Tag Size xchacha20-ietf-poly1305 32 32 24 16 chacha20-ietf-poly1305 32 32 12 16 aes-256-gcm 32 32 12 16 aes-192-gcm 24 24 12 16 aes-128-gcm 16 16 12 16
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 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.
Name Key Size Salt Size Nonce Size Tag Size xchacha20-ietf-poly1305 32 32 24 16 chacha20-ietf-poly1305 32 32 12 16 aes-256-gcm 32 32 12 16 aes-192-gcm 24 24 12 16 aes-128-gcm 16 16 12 16
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 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
- A SIP003 plugin for traffic obfuscating: simple-obfs.
- A shadowsocks implementation based on SIP003: shadowsocks/shadowsocks-libev.
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 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 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 provide only confidentiality. Data integrity and authenticity is not guaranteed. Users should use AEAD ciphers whenever possible.
The following stream ciphers provide reasonable confidentiality.
Name Key Size IV Length aes-128-ctr 16 16 aes-192-ctr 24 16 aes-256-ctr 32 16 aes-128-cfb 16 16 aes-192-cfb 24 16 aes-256-cfb 32 16 camellia-128-cfb 16 16 camellia-192-cfb 24 16 camellia-256-cfb 32 16 chacha20-ietf 32 12
The following stream ciphers have inherent weaknesses (see discussion at #36). DO NOT USE. Implementors are advised to remove them as soon as possible.
Name Key Size IV Length bf-cfb 16 8 chacha20 32 8 salsa20 32 8 rc4-md5 16 16
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 provide only confidentiality. Data integrity and authenticity is not guaranteed. Users should use AEAD ciphers whenever possible.
The following stream ciphers provide reasonable confidentiality.
Name Key Size IV Length aes-128-ctr 16 16 aes-192-ctr 24 16 aes-256-ctr 32 16 aes-128-cfb 16 16 aes-192-cfb 24 16 aes-256-cfb 32 16 camellia-128-cfb 16 16 camellia-192-cfb 24 16 camellia-256-cfb 32 16 chacha20-ietf 32 12
The following stream ciphers have inherent weaknesses (see discussion at #36). DO NOT USE. Implementors are advised to remove them as soon as possible.
Name Key Size IV Length bf-cfb 16 8 chacha20 32 8 salsa20 32 8 rc4-md5 16 16
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