End to End encryption for channels using channel passwords

[GIJack]

Asymmetric crypto is hard to implement. Mostly because you need key infrastructure. Getting Asymmetric crypto working in a group chat where everyone needs eachothers keys set up properly? Then make sure those keys are valid? good luck in real world conditions for most people. Rare.

Symmetric crypto is really easy. All you need is a key.

Suggestion. add another channel mode -K that functions like -k(password to join), but instead of server enforced password, uses locally stored password, that gets hashed to generate a key.

Support passwords and keyfiles

Recommended is AES256GCM and 2 thousand rounds of SHA512 for the password.

[SadieCat]

Why bother with end to end encryption if the server knows your password anyway? You might as well just require TLS.

[GIJack]

I wasn't suggesting leaving the password on the server. It would just be -K, and it would be implied that the password is stored locally.

[SadieCat]

If your password is ever known to the server it can be recorded by the server which makes any "end to end" encryption using it pointless.

[kaniini]

Symmetric encryption is possible, but not in the way you describe. I would suggest using client-to-client tags to do a DH-style key negotiation to establish a session key. Assymetric encryption does not always mean PKI.

[GIJack]

SaberUK,

The idea would be the password would be shared out of band, by users, perhaps in a private encrypted chat setup with other crypto.

You are also making the assumption that a server will always be capturing all traffic all the time, as opposed to just opening tcpdump at an event after being prompted, which is more likely threat model.

In any case, out of band password sharing for a large channel where trying to use asymmetrical crypto would not be possible. Perhaps even someone could write a bot that automatically gives out and updates the channel key and distributes it privately using asymmetric crypto.

[SadieCat]

You're essentially advocating for OTR but harder to use and less secure. Barely anyone uses OTR and even less people would use this .

Olm/Megolm was proposed in #29 because its realistically the most feasible we have right now. If you don't like that please provide valid criticism rather than just vague sentences like "hard to use".

[GIJack]

How would this be harder to use. It would simply be a password that gets hashed to an encryption key. That is really simple.

It solves two problems. One, getting everyone to exchange keys, and the overhead needed for a massive channel where every message needs to be encrypted to every key.

People just need a single password, or alternative, a keyfile.

[DarthGandalf]

@GIJack how is this different from existing FiSH? Except that you also mentioned +K mode which does nothing?

[SadieCat]

It would simply be a password that gets hashed to an encryption key.

Hashing something that the server has already seen in plaintext is pointless.

Please do some actual research into how cryptography works before suggesting unworkable ideas.

[jesopo]

I disagree with this idea overall but it's important to understand that the key would explicitly not be sent to the server at any point; it would be shared out of band and used as a symmetric key

[GIJack]

@DarthGandalf - the point is taking something like FiSH and making it an RFC so its part of spec.

[TingPing]

fish is pretty widely implemented so step one is probably documenting all of what existing implementations do.

Whether or not it belongs in IRCv3 it would be useful to be documented better.

[GIJack]

As far as FiSH goes, it is yesterdays protocol with exploits against current implementation and uses insecure mode of encryption.

[Mikotochan]

@GIJack

Recommended is AES256GCM

Anything other than chacha20-poly1305 is crap.

and 2 thousand rounds of SHA512 for the password.

This should be an implementation detail. I personally would suggest random keys, pbkdf2, or argon2i.

@SaberUK

You're essentially advocating for OTR but harder to use and less secure

No, he is not, plus it is actually more secure (OTR uses 128-bit AES and 1.5k DH).

Originally my post also contained:

Please do some actual research into how cryptography works before suggesting unworkable ideas.

It is actually very workable. I did not expect from a computercraft user to know any better though.

But it was removed by DanielOaks, I have no idea who jwheare is and I haven't seen them post anything about "snide comments", even if they did though I would not care about what someone who develops non-free software and uses a picture of their face online has to say. Also, I find it highly hypocritical of DanielOaks to censor my post where I claim that said ideas are actually very workable and not censor the insulting and factually incorrect one which I am quoting -- I would not expect any better from people who censor the posts of others though.

[DanielOaks]

@Mikotochan don't make snide comments about other users or as @jwheare has already said you will be blocked.

[TingPing]

As far as FiSH goes, it is yesterdays protocol with exploits against current implementation and uses insecure mode of encryption.

It can be easily extended for new modes.

[nektro]

having channels that require a password is a decent idea but "End to End encryption" should not be in the title as that is something totally different