wishlist: perfect forward secrecy & deniable authentication

[aaannndddyyy]

Having OTR-like security for group chat would be a very good selling argument for fox.

[aaannndddyyy]

In a group with n+1 peers / group members: n times DH per session, and for each sent packet: crypto_stream_xor for encryption, used once per packet you send. crypto_auth used n times per packet you send.

Instead of n times crypto_box.

This way you can easily get otr features for groups:

• perfect forward secrecy
• authentication
• deniability

[aaannndddyyy]

@JFreegman stated wrongly that it is insecure to share encryption keys (just think of public keys, you can share them and it is not a security compromise either). All peers in the group already know the plain text messages. If they leak the key it was encrypted with, they could as well just forward the plain text messages. They would not gain anything "compromising" the key. If they leak the key it has no consequences whatsoever neither for secrecy of the messages nor for authentication of messages.

Anyway, he said he is not willing to change the encryption scheme. That's fine. As I pointed out, this is not needed for the desired features. Without that PFS and deniable authentication are possible. Then a group chat will bascially just be n 1:1 chats. Each peer in a group basically opens a 1:1 chat with each other peer and sends each message inteneded for the group or room in each of the 1:1 chat sessions, and gathers all their messages in a single window. This is ocmputationally more expensive, but it can be done. As tox already has the desired features in 1:1, groupchat would inherit them. There must however be no signing of chat messages for history sync. The sync would be untrusted, or you could sync with two peers and trust that if both report the same, it is veritable.

[JFreegman]

@aaannndddyyy If you think there is no issue with sharing a secret key with the public then you really have no place speaking on anything related to encryption. We appreciate feature requests and improvement suggestions, but please leave the implementation details to the developers.

[aaannndddyyy]

@JFreegman Yes, I do think that sharing that key is not an issue. Please stop being so arrogant. If you don't see my point or don't want to explain why this would be dangerous in your eyes, fine. Just don't state it as if it were a fact. Had I not pointed out that you only need one key in the chatid, you would probably still not know that you don't need two, otherwise, why was it implemented using two?! So my implementation comments are not useless. You can share a symmetric key with the one who you want to be able to decrypt you messages, yes. That is how symmetric encryption works. Right now you share the secret key already. You share it with one. So you need n different shared secret keys. To encrypt the very same message. This is unnneded and you gain no additional secrecy. You gain no anonymity (we are talking about encryption, not anonymity), you gain no authentication you'd not have in my scheme (we are talking about encryption, not authentication), nothing. A constructive comment by you would have been along the lines of "I think this is not a good idea, because ..."

[landswellsong]

@aaannndddyyy to clarify, are you speaking about Multiple Party Diffie Hellman Key Exchange or you have something other in mind?

[alnf]

@aaannndddyyy The problem is that we don't understand what you mean. You should try to be more clear. We don't share any keys except public peers keys. I'm not sure what you mean by secret. Common symmetrical key or what? Also I know that one can convert sig key to enc from the start. However to use both authenticated encryption and public key signature you need two pair of keys, so we believe that storing both is convenient (no matter whether you created two pairs of keys which are independant or converted one key pair from another) in comparison with converting all the time.

[aaannndddyyy]

@landswellsong I am talking about nicely scaling dynamic group DH key exchange with conference key and peer authentication, with the properties of perfect forward secrecy and deniable authentication (repudiability), where each user in the group can be sure that a message received from another peer was really authored by that very peer and not just any group member. @alnf : "converting all the time"?? You'd convert only once, namely when you start the intend to join a group. You can save the key so that even after restart you still have it and need not derived it again, but there is absolutely no need to have both in an id! With DH you DO share a secret, that is what DH is all about. So you do not only share public keys. You exchange public keys in order to derive a shared secret which you use in order to seed your stream cipher (symmetric). As to being more clear, this is just the issue tracker. If there were interest in any details, we could have talked about it in tox or you could have requested some specs for it (I won't write a lot, if there is absolutely no interest in it, sorry) or I could have given some links.

But as I "really have no place speaking on anything related to encryption", I'll shut up. No need to lock this thread, too. Good luck!

As solicited, any further comments by me will only be about feature requests, if at all.

[landswellsong]

@aaannndddyyy

With DH you DO share a secret, that is what DH is all about. So you do not only share public keys. You exchange public keys in order to derive a shared secret

See the problem is, you use wrong terminology, which confuses us here. Deriving a shared symmetric key is strictly not called sharing. What you are describing is basically multiparty DH and you could have just mentioned that which would be perfectly undersood. That would indeed make some sense but as far as it goes right now, this would require a deep work inside libsodium, because they bake they crypto_box as a pretty high level promitive, abstracting up from a great deal of detail.

Just in case, that's how it works: http://cr.yp.to/highspeed/naclcrypto-20090310.pdf

[aaannndddyyy]

I know how it works. And as for "sharing", a shared secret is shared. That's why it is called shared secret. That's the term for it. Peers share a common secret. That's how it works. How do they get the shared secret? Not by sending it to each other; this does not mean it is exchanged over the wire.

[alnf]

@aaannndddyyy "no need to have both in an id" - it's the matter of coding style, whether we have two separate variables, which contains two keys, or one, which contains two keys. We are not planning to send both keys in the packets, also the packets structure is changing with the new ideas, so wiki is not up to date.

So, once again, are you talking about Multiple Party (or it is also called Group) Diffie Hellman Key Exchange or no?

[aaannndddyyy]

Coding style?! save it in one variable if you wish. But coding style is not an argument for making id's that users must exchange, longer than needed. The length should only be determined by security considerations (mainly key length), not coding style. And of course, I was talking about multiple party diffie hellman, what else would DH stands for in this context? I don't care, leave it as it is. I will restrict myself to feature requests only, and those I have stated already: 1) shorter chatid's or group id's, 2) perfect forward secrecy, 3) deniable authentication of each packet's author.

[landswellsong]

@aaannndddyyy then you should realize that multiparty DH does not scale nicely at absolute all. I would be a nightmare to sync in an active chat not to mention to a myriad of ways to abuse groupchats because of that. This would only be a good idea for an established group of stable peers, otherwise the benefits of doing this just don't cover the drawbacks.

[aaannndddyyy]

And you should know that there is not just one way of multiparty DH. It scales with O(m²) network-wise, just like what I think your current approach is. So no drawbacks compared tu current. Advantage would be speed though. (hashing once, encrypting once, MAC m times. as opposed to hashing m times, encrypting m times, MAC m times). Of course, a sign-once approach scales much better, but does not have the otr-like features anymore. Any signing destroys that, also your planned chathistory sync signing, of course. I'd rather consider history sync ans an untrusted service. Compare syncs with two random peers to gain more confidence, if you need. Over and out.

[landswellsong]

The current approach indeed has space for improvement, but still the messaging part is not dependent on the key exchange magic which would mean inevitable slowdowns when a person joins the chat. And it's going to be even more pronounced with AV.

Anyway, we'll consider that, thanks. Just in case, please do mention primitives you mean explicitly as it's not that easy to infer what the person is saying as it might look like.

[alnf]

@aaannndddyyy "id's that users must exchange" You are not reading carefully, I said that we are not planning to send both keys together in the packets and that is the main message. Changing code style to use two variables instead of one is not top priority in comparison with optimizing packets structure or writing tests.

"Length should only be determined by security considerations" - what do you mean by security consideration here? How do you see the potential exploits here?

[aaannndddyyy]

My goodness! I mean do make the key as long as needed for your given keylength, but not longer. I.e. not include two keys if you do not need to include two keys. I don't care about code style, I am talking about the chatid, the thing you give the usersso that they can join your group. That ticket has long been closed, so I assume you already changed the code accordingly. There was agreement on that already. If you can derive the other key you are free to ultimately save both in one variable or two, or if you want five. There is also no need to send the derived key in any packets, but that's nothing that would bother the user. Short id's were the other ticket, should be implemented by now. This one here was about PFS and repudiability. Forget I ever mentioned multiparty DH. You can achieve these also with m 1:1 sessions.

[aaannndddyyy]

https://en.wikipedia.org/wiki/Forward_secrecy http://www.forwardsecrecy.com/ http://www.perfectforwardsecrecy.com/ https://en.wikipedia.org/wiki/Deniable_authentication https://en.wikipedia.org/wiki/Off-the-Record_Messaging https://en.wikipedia.org/wiki/Plausible_deniability https://en.wikipedia.org/wiki/Malleability_%28cryptography%29 https://otr.cypherpunks.ca/ https://csclub.uwaterloo.ca/media/Off-the-Record%20Messaging:%20Useful%20Security%20and%20Privacy%20for%20IM.html (features otr is famous for, and tox gc should have too)

[alnf]

@aaannndddyyy I wrote it again, because you said "Coding style?! save it in one variable if you wish. But coding style is not an argument for making id's that users must exchange, longer than needed." So I derived from that phrase that you did not understand that we do not want to force users to exchange long keys, which means the issues now is only about how to store the keys. And long key (instead of two varibales) was introduced long long time ago, even before libsodium introduced conversion function.

Also you said "The length should only be determined by security considerations (mainly key length), not coding style." I really wonder what you meant by security considerations. Maybe some example will help me to understand.

About current implementation:

• authentication and encryption is achieved by mutual authenticated encryption
• forward secrecy is going to be achieved by session keys (as it is done in the current core), however, for cases where you create new key pair every time you join the chat it might be unnecessary
• deniable authentication is naturally derived by using authenticated encryption (http://nacl.cr.yp.to/box.html read Security model section)
• signature (I mean public-key signatures) is used only when we need to create a message, which anyone can read and authenticate the author, even though the author might be offline

By "multiparty DH does not scale nicely at absolute all" @landswellsong probably meant that adding/deleting of new peers is very troublesome. How does your version of multiparty DH deals with that, cause I didn't understand.

[JFreegman]

@aaannndddyyy

I am talking about the chatid, the thing you give the usersso that they can join your group. That ticket has long been closed, so I assume you already changed the code accordingly. There was agreement on that already.

The chat_id will be comprised of the group's public signature key, which is 32 bytes long. I haven't pushed the code yet but it's pretty much done. So yes, you're right. That issue is resolved. Let's try to keep these issues separate - the size of the chat_id has little to do with OTR-like features.

[JFreegman]

You just made a wrong statement in the other issue and locked it ....

First of all, if I lock an issue it means the discussion is over. It does not mean bring the discussion to another issue that's completely unrelated. Second of all, sharing a long-term secret key with a group of untrusted peers is bad and wrong. If you meant something else then you were not clear. If you don't tone down the antagonism you're going to be blocked from commenting on this repo.

As far as deniable authentication goes, our chat keys are not tied to our tox ID's, meaning as long as we change our keys periodically there is no issue. However we're not at the point where we're ready to worry about this yet.

[alnf]

@aaannndddyyy Regarding: ""signature (I mean public-key signatures) is used only when we need to create a message, which anyone can read and authenticate the author, even though the author might be offline" Which destroys deniable authentication, so you can no longer say that you have deniable authentication in your groupchats, or that your groupchats have the features of OTR, if you do that."

What do you propose to use then for operators ban certificates, which have to be valid for the entire chat lifetime?

[aaannndddyyy]

@alnf you don't want repudiability for administrative action. But you want it for chat messages. I clearly stated that. So this is about your planned chat history history sync. It does not apply to certificates, those need to be signed.

[alnf]

@aaannndddyyy We are not going to sign chat messages, signature applies only for certificates.

[aaannndddyyy]

then your wiki should be updated ("(we're also considering signing each message for custom sync mechanism independent of transfer protocols, see sync doc).") I can remove that, as it's apaprently no longer the case.

[JFreegman]

@aaannndddyyy Please do not modify the wiki. I'm not sure why you even have access to it.

[aaannndddyyy]

because that's how wiki's work. By collaboration.

[alnf]

@aaannndddyyy Yeah, I already wrote several posts above, that wiki is not up to date. Don't bother to edit, we are going to rewrite some parts. @JFreegman I think the access to wiki on github is for everyone, I didn't not modify any rights.

[aaannndddyyy]

@alnf you should update it then

[aaannndddyyy]

it is of little use if it holds outdated information

[JFreegman]

@aaannndddyyy I'm more a fan of the privilege myself. It makes me feel superior to you lowly non-developers.

[JFreegman]

But on a serious note, we use the wiki to keep track of our own progress, which means when people change stuff without us knowing, it makes things very confusing. For this reason we're going to set it to collaborators only mode.

[alnf]

@aaannndddyyy "How does crypto_box deal with the well-known source substitution attack on some DH-based AKE's" https://blog.tox.im/2014/04/27/how-the-crypto-tox-uses-works/

Also I'm still interested in how does your version of multiparty DH deal with adding/deleting of new peers, cause I didn't understand.

[alnf]

"But on a serious note, we use the wiki to keep track of our own progress, which means when people change stuff without us knowing, it makes things very confusing."

I would agree here. No offence to anyone. There are some outdated parts of wiki and not. There are some old ideas or not so good ideas (which we still want to keep, cause it's like a basis to generate new better ideas). We use wiki more like a note desk for ourselves (which will eventually lead to official doc). So, I think I want to have a total control over it. Let's use issues if we want to address some changes in the wiki.

[alnf]

@aaannndddyyy "This link has no meaningful informatio wrt to that attack. The information there is too superficial. It is more a How-To than a cryptographic spec, sorry."

Following the links in the end of the page, especially to nacl implementation, you can find articles with more formal definitions.

[alnf]

"Anyway, do it on your own. But do it in a timely manner! I'm not good at reading C code. So I read your docs. And currently your docs say that you are considering to take the features of deniable authentication away."

@aaannndddyyy We would be really happy to keep the wiki up to date, however, working on groupchats takes a lot of time, considering that we all have our personal circumstances and obligations not related to tox. This work is entirely volunteer, so we would appreciate your patience. If you don't agree with smth written in the wiki, please, create an issue. And we will answer if that information is up to date and how we plan to deal with it.

[aaannndddyyy]

@JFreegman you really don't get it?! There is no issue with sharing that key. I request you stop with your arrogance and aggression. If you don't understand something, then there is something our ancestors invented. It is called asking. Second, if you think that you can sign a chat message with your longterm group chat I'd and still have deniability and call it otr-like, then I want to try the same drugs you are on. I don't think anybody should trust software made by someone who states so blatantly wrong things. It seems you do not even understand what repudiability means. Come on, it ain't that hard. Just try!

[aaannndddyyy]

@alnf if a peer leaves voluntarily nothing needs to be done, the key can stay the same. It makes no difference to the group. He is not receiving the ciphertext anyway. And if another still connected peer forwards the ciphertext to him, he can still decrypt it. However, that is not an issue; the forwarder could as well forward the decrypted message. In either case there is no message authenticity proof for the former member. Same applies to blocked/banned peers. Only exception would be if you want to protect against former group members who can monitor the connection of other peers, like an ISP. In that case it needs one round of n messages to change the key.