Unifying chacha20-poly1305 ciphers about shadowsocks-org HOT 39 CLOSED

Just use the following alias:

1. chacha20-ietf-poly1305 to AEAD_CHACHA20_POLY1305
2. 'aes-128-gcmtoAEAD_AES_128_GCM`
3. 'aes-192-gcmtoAEAD_AES_192_GCM`
4. 'aes-256-gcmtoAEAD_AES_256_GCM`

from shadowsocks-org.

Simplify is the beginning of confusion.

I think adding the detail you listed is useful.

from shadowsocks-org.

No. Don't do this. This may be even more confusing.
Deprecating unused ciphers is effective enough.

from shadowsocks-org.

AFAIK xchacha20-poly1305 was never implemented, and chacha20-poly1305 was removed anyway. There's only chacha20-ietf-poly1305 variant available, and it's silly for users to remember the extra ietf thing if that's the only one we support.

OpenSSH didn't call their implementation [email protected] and TLS didn't call their cipher suite TLS_CHACHA20_IETF_POLY1305_SHA256.

If we want the AEAD cipher to be widely adopted, we should prefer one to make it easier for clients to pick.

from shadowsocks-org.

I'm afraid renaming cipher is not an option. It solves fewer problems than it causes.

from shadowsocks-org.

Why not? AEAD ciphers are only supported in three implementations so far. It's much better to stick with one name before more implementations make the same mistake.

from shadowsocks-org.

Because I'm afraid it's already too late. 😅

from shadowsocks-org.

It's less than one month old. There's still plenty of time to fix it ^_^

from shadowsocks-org.

Nah. Methinks the current approach is better even if you proposed this before ss-libev implements it. We need consistency between non-AEAD variants chacha20-ietf and chacha20.

from shadowsocks-org.

The consistency only makes sense if we have both chacha20-ietf-poly1305 and chacha20-poly1305. We have just one, and it's the default one. It should have shorter, consistent name with every other use case e.g. OpenSSH and TLS.

from shadowsocks-org.

Having internal consistency is more important than being consistent with some other libraries.

from shadowsocks-org.

BTW chacha20 stream cipher is deprecated due to its 64-bit IV.

from shadowsocks-org.

Deprecated isn't the same as removed. And even if it's removed it's still more confusing to rename it. It's generally a bad idea.

from shadowsocks-org.

So past mistakes stick forever? I bet not.

from shadowsocks-org.

This is the chance to fix legacy issues.

from shadowsocks-org.

So past mistakes stick forever? I bet not.

Unfortunately this is very true, at least in this field.

from shadowsocks-org.

I beg to differ. TLS 1.3 draft used to use 64-bit nonce variant AEAD_CHACHA20_POLY1305. They changed it to 96-bit nonce (effectively the IETF-variant) while keeping the name. In fact, AEAD_CHACHA20_POLY1305 is now formally defined in RFC 7539. We should follow the standard.

from shadowsocks-org.

TLS 1.3 draft

from shadowsocks-org.

AEAD_CHACHA20_POLY1305 is now formally defined in RFC 7539. We should follow the standard.

from shadowsocks-org.

Maybe add chacha20-poly1305 as alias to chacha20-ietf-poly1305 in shadowsocks? Then, everyone would be happy...

from shadowsocks-org.

@madeye I was thinking exactly the same! 👍

from shadowsocks-org.

@riobard That doesn't prove anything. A draft is by definition subject to change. And this is different.

@madeye Probably not. Now you have a compatibility problem which is much worse.

from shadowsocks-org.

You can't just finalize a draft and change your mind. Absolutely no.

from shadowsocks-org.

I don't see a tag anywhere saying this is "finalized".

from shadowsocks-org.

Even if nobody has said the word "finalized" there are also quite a few synonyms:

• #30 is closed.
• shadowsocks-libev released v3.0.3 as a stable version without any signs like 🚧 or AEAD subject to change. (see this warning for example)
• Neither can anyone find stuff like that in spec.
• Having a spec page also implies it's finalized.

from shadowsocks-org.

Hmm, confusion is the biggest concern, especially for our normal users. I suggest at least keeping the name chacha20-ieft-poly1305 in shadowsocks, which won't break anyone's config files.

from shadowsocks-org.

If you really want to make this change, start putting construction signs everywhere mentioning AEAD and I won't object this any more.

from shadowsocks-org.

I'd like to know which implementation has both chacha20-poly1305 and chacha20-ietf-poly1305, and who actually deploys the former in practice?

from shadowsocks-org.

Fine whatever. I'm done wasting my time discussing naming issues.

from shadowsocks-org.

Just follow the name used in crypto libraries, as Shadowsocks doesn't provide this.

from shadowsocks-org.

@hellofwy Not all implementations use the the same crypto libs. It's better to stick to RFC.

from shadowsocks-org.

is RFC 7539 a well implemented RFC?

If standardize this cipher name, maybe should standardize all the cipher names as well, and provide a table which lists corresponding names in crypto libraries.

And provide infos about from which version begin supporting all the new names.

from shadowsocks-org.

There are two relevant RFCs:

• RFC 5116 specifies general AEAD interfaces and AES-128/192/256-GCM in particular
• RFC 7539 specifies Chacha20-Poly1305

Other ciphers are not well defined.

from shadowsocks-org.

Ok. If renaming old cipher is unacceptable, may I propose that we adopt the IANA AEAD registry? http://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml

from shadowsocks-org.

At least each one in that list has a well-defined specification.

from shadowsocks-org.

@Mygod This does not rename old ciphers. I guess you might be OK with it?

from shadowsocks-org.

Best thing with the IANA registry is that they assigned a unique numeric ID for each cipher suite. Should be easier to deal with in code.

from shadowsocks-org.

It's kinda better. But I honestly don't care any more.

from shadowsocks-org.

Closing now. New proposal at #61.

from shadowsocks-org.