-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIP004 - Support for AEADs implemented by large libraries #30
Comments
My plan is forking ourselves, dropping all the support of stream ciphers and OTA. After that the we can provide a new version of the protocol (v2?). |
I want to clarify AES-GCM is the fastest on machines with particular instruction sets, for example, server and client are both running on modern Intel CPU. |
I agree with #30 (comment) |
I don't see the reason to drop compatibility for stream ciphers for now as @madeye has said:
People who has higher security standards could migrate to using these algorithms. And if benchmark shows its influence to performance is negligible we should start to encourage everyone to migrate to AEADs. And I don't think adding these additional algorithms would be a lot of work (we need at most 1 more abstraction layer). |
They can coexist as different projects, it is easy to maintain IMO. |
Considering SIP003, I think it's easier to maintain if implemented in one single project. |
To support AEADs, first we need to define chunks for the TCP stream. Here is a proposal:
Assuming average data length equals to a typical MTU - 26 (1492 - 26 = 1466), then the maximum transfer efficiency is 1466 / 1492 = 98%. |
So which part of the chunk is encrypted? DATA? Or the whole chunk? Or both of them? |
@Noisyfox DATA.LEN, NONCE and TAG should not be encrypted. Only DATA is encrypted. TAG is generated from encrypted DATA. For more details: https://github.com/lparam/xSocks/blob/master/src/crypto.c#L25 |
That's basically the pattern of TLS record if I did understand correctly. |
@Noisyfox Yes, exactly. |
xsocks' looks like https://github.com/jedisct1/libsodium/blob/master/src/libsodium/crypto_secretbox/xsalsa20poly1305/ref/secretbox_xsalsa20poly1305.c It is AE not AEAD. |
Is DATA.LEN necessary? @wongsyrone I don't think we need AEAD actually? |
@Mygod Yes, I think so. It's required to split TCP stream to chunks. |
AE:
AEAD:
AEAD can protect plain text as well. |
@madeye What about letting it equal to packet length - 24? @wongsyrone I don't think we have non-confidential data to protect however. |
@Mygod In a TCP stream, there is not packet length... |
Oh sorry I got confused because you mentioned MTU. 😅 |
MTU here is only to demonstrate how large a chunk could be in the real world... In our implementation, we should also limit the DATA.LEN, make it smaller than the socket buffer size, e.g. 2048 in shadowsocks-libev. |
NONCE is too short.
|
Then what about this:
SEQ is a 64-bit sequence number. The real NONCE is SEQ+ NONCE. DATA.LEN + SEQ is also the AD of the AEAD. (Why shouldn't I use TLS directly? 😅 ) |
[draft] main idea from @breakwa11 and @Noisyfox Please note that this is not compatible with current OTA and original protocol. /*
* The main difference between OTA designed by madeye and this one is MtE vs EtM.
*
* The first nonce is either from client or server side, it is generated via randombytes_buf()
* in libsodium, and the sequent nonces are incremented via sodium_increment() in libsodium.
* Please note that sodium_increment() considers the number to be encoded in little-endian format.
* IMPORTANT: nonce should be used only once, let us running on the right track.
*
* Data.Len is used to separate general ciphertext and Auth tag. We can start decryption
* if and only if the verification is passed.
* Firstly, we do length check, then decrypt it, separate ciphertext and attached data tag
* based on the verified length, verify data tag and decrypt the corresponding data.
* Finally, do what you supposed to do, e.g. forward user data.
*
* For UDP, nonces are generated randomly without the incrementation.
*
* TCP request (before encryption)
* +------+---------------------+------------------+
* | ATYP | Destination Address | Destination Port |
* +------+---------------------+------------------+
* | 1 | Variable | 2 |
* +------+---------------------+------------------+
*
* TCP request (after encryption)
* +--------+-----------+---------------+----------+---------------+
* | NONCE |PayloadLen |PayloadLen_TAG | Payload | Payload_TAG |
* +--------+-----------+---------------+----------+---------------+
* | Fixed | 2 | Fixed | Variable | Fixed |
* +--------+-----------+---------------+----------+---------------+
*
* Payload input: atyp + dst.addr + dst.port
* PayloadLen is length(atyp + dst.addr + dst.port)
* Payload_TAG and PayloadLen_TAG are in plaintext
*
* TCP Chunk (before encryption)
* +----------+
* | DATA |
* +----------+
* | Variable |
* +----------+
*
* Data.Len is a 16-bit big-endian integer indicating the length of DATA.
*
* TCP Chunk (after encryption)
* +------------+---------+-----------+----------+
* | Data.Len* | Len_TAG | DATA_TAG | DATA* |
* +------------+---------+-----------+----------+
* | 2 | Fixed | Fixed | Variable |
* +------------+---------+-----------+----------+
*
* Len_TAG and DATA_TAG have the same length, they are in plaintext.
* After encryption, DATA -> DATA*
*
* UDP (before encryption)
* +------+---------------------+------------------+----------+
* | ATYP | Destination Address | Destination Port | DATA |
* +------+---------------------+------------------+----------+
* | 1 | Variable | 2 | Variable |
* +------+---------------------+------------------+----------+
*
* UDP (after encryption)
* +--------+----------+-----------+
* | NONCE | DATA* | DATA_TAG |
* +--------+----------+-----------+
* | Fixed | Variable | Fixed |
* +--------+----------+-----------+
*
* DATA* is Encrypt(atyp + dst.addr + dst.port + DATA)
* RSV and FRAG are dropped
* Since UDP packet is either received completely or missed,
* we don't have to keep a field to track its length.
*
*/ |
I don't see the point of "length-tag". AEAD support additional data to be authenticated as plaintext. You can use length as the "additional data" for temper proofing. |
@v2ray Agreed. The DATA.LEN can be protected by AEAD as plaintext. |
+1. But this reminds me that we need random noise indistinguishability more than authentication (i.e. IND-CCA2) since the original purpose of this repo is to circumvent GFW and it's much harder to perform a realistic CCA2 distinction. Let's review our additions against random noise indistinguishability:
OTA also has this problem. So what do you think? |
removes some of my useless comments Okay I think I got this sorted out. What we need to do is just to put data.len in the encryption data; send nonce ONLY in the first data and it auto increments for EVERY data. And voilà! |
FYI: http://github.com/v3aqb/hxsocks
Mygod <notifications@github.com>于2017年1月18日周三 22:52写道:
… *removes some of my useless comments*
Okay I think I got this sorted out. What we need to do is just to put
data.len in the encryption data; send nonce ONLY in the first data and it
auto increments for EVERY data. And voilà!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADJX912UsW4SkbvZFxqimnrr4D1YHvz4ks5rTicZgaJpZM4Lhapt>
.
|
I beg to differ. I took a quick glance and you implemented what shadowsocks was designed to prevent. |
@madeye Chunks are not the pattern, but the length of the chunks is. The reason why I support AEAD ciphers is just that AEAD ciphers are widely used in current practice. |
Please note that SIP004 is superseded by SIP007 (#42). |
从梅林被老司机领到这里,我就想问问大家,有什么决定性的代码或者证据证明OTA是先天不足必须给钦定的AEAD让路么?如果有,请联系我,我提供个C段地址,求扫描 |
@tigaly |
@hellofwy 这篇文章针对OTA不就是那个很容易fix的漏洞么(通篇吹破哇)?还有什么直接证据呢?那么,出于安全级别的考虑有没有什么别的漏洞无解呢? |
@tigaly |
@hellofwy 我并不是在意安全问题,我只是用梅林的时候发现了OTA更新被直接干掉了,才想来学习下,不过这种漏洞解决的方式真奇怪哈,要是哪天证明AEAD也有问题?是不是要搞个DEAD协议出来? |
😁
Tigaly <notifications@github.com>于2017年2月11日周六 17:15写道:
… @hellofwy <https://github.com/hellofwy>
我并不是在意安全问题,我只是用梅林的时候发现了OTA更新被直接干掉了,才想来学习下,不过这种漏洞解决的方式真奇怪哈,要是哪天证明AEAD也有问题?是不是要搞个DEAD协议出来?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADJX95YIfhgttUg1oyZokmqjpqalb8X1ks5rbXwXgaJpZM4Lhapt>
.
|
@tigaly 既然不在意安全问题,那你直接用最早的版本的协议就好了,用OTA干什么?OTA本质就是增强安全为目的设计的 |
@tigaly |
@breakwa11 那你去掉OTA就是为了安全?有没有证据可以证明呢?我并不在意安全问题,并不是我心大到完全不在意安全,只要gfw探测不到就行了 @hellofwy 我当然知道,只是开玩笑的说法,对于大家这种严谨的做法,我真是大开眼界 |
@tigaly 什么叫做“我去掉OTA”?????????? |
@breakwa11 除了你还有谁一直在鼓吹OTA有不可修复的漏洞? |
所以我也可以说:windows和linux有一大堆漏洞,然后修复漏洞的人就是我了,是这种逻辑吧,太好了,成百上千的都是我弄的 |
@breakwa11 你这手驴打滚偷换概念玩的6,我也懒得跟你说,OTA和AEAD这两个功能的更替,有多少你在里面带节奏,明眼人一看就知道,不是你想推脱就推脱的 |
那不然呢?SS的代码我一行没动,在一行没动的情况下就成了是我改的?我不动一根手指但几千代码都是我改的,哇,难不成你说madeye的号被盗了? |
@tigaly @breakwa11 Please stop posting any irrelevant comments here. |
@breakwa11 有种叫教唆犯你不会没听过吧 |
@tigaly |
@hellofwy 是啊,本来说的好好的,不知道哪来的人跳出来一阵节奏和歪楼, |
@tigaly abandon of OTA is discussed,cannot undo. Besides one saying says U
can U up, talk is cheap show your code <notifications@github.com>于2017年2月11日
周六17:52写道:
… @hellofwy <https://github.com/hellofwy> 是啊,本来说的好好的,不知道哪来的人跳出来一阵节奏和歪楼,
另外我翻了下好多关于OTA的讨论都完全被人带节奏,TLS和SS的用途被混为一谈,我就不说了,反正我也不怎么用ss,你们大家慢慢加油吧
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF8zURTYKZkvqwLxQK7LMDPlkrqd5IRqks5rbYTlgaJpZM4Lhapt>
.
|
@qiuyuzhou 我进这个讨论组第一句话就说了,谁能针对OTA探测,求扫描,我提供一个C段地址,只是其他人一直歪楼带节奏才变成这样 |
U can privately send ur IP to breakwa11,instead of start a fight here.
Tigaly <notifications@github.com>于2017年2月11日 周六18:03写道:
… @qiuyuzhou <https://github.com/qiuyuzhou>
我进这个讨论组第一句话就说了,谁能针对OTA探测,求扫描,我提供一个C段地址,只是其他人一直歪楼带节奏才变成这样
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF8zUR1A8a55nUWb_A6jeHgY-66reb-Zks5rbYd_gaJpZM4Lhapt>
.
|
@qiuyuzhou 如果她敢接就不会一直打嘴仗了,从sadoneli一直扯到这里来 |
She already post her pubkey,just gpg encrypt it and post your encrypted IP
here
Tigaly <notifications@github.com>于2017年2月11日 周六18:08写道:
… @qiuyuzhou <https://github.com/qiuyuzhou> 如果她敢接就不会一直打嘴仗了,从sadoneli一直扯到这里来
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#30 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF8zURgP3a1rL2Rt3ZPSSvEoO626fXq4ks5rbYiYgaJpZM4Lhapt>
.
|
Locked as off-topic. |
@tigaly 你@错人了。。。 |
Use AEADs to replace stream cipher + OTA. Previous discussion: #29.
Proposed AEAD algorithms:
Update: The following shows an example of TCP stream in chacha20-ietf-poly1305 mode (original idea by @breakwa11 and @Noisyfox). Other AEAD should follow the similar format.
The text was updated successfully, but these errors were encountered: