On 15/11/18 13:10, Ismail Kizir wrote: > Hohha Protocol is a quantum safe communication protocol. > This is the techinal whitepaper draft of our Hohha Messenger which > we'll publish soon with a MIT Licence. > Any contribution and or comment will be appreciated. > Link is a sharable link of a Google Docs document. > > https://lnkd.in/gpPXW8n Just had a quick look. It's a bit of a hodge-podge, isn't it. But there's worse: 1] The key renewal is worse than useless. If an existing key is not known to Alice, there is no reason to renew it - if it is known to Alice, she can deduce the new key. So it's useless. It's worse than useless because it introduces complexity and attack surface. KISS. I don't know of an attack on that part of the protocol offhand, but why take the chance? 2] It uses an untested ?proprietary? roll-your-own algorithm. Ouch. Why not use something tested? Why allow an untested option, even as an option? 3] it can be forced back into using quantum-insecure DH. Ouch. Mallory will have fun... 4] it places too high a burden on the user. Users are clueless about security, that's our job, not theirs. 5] it relies on a trusted server. So overall, it's a hodge-podge piece of cr#p, written by someone with no clue about protocol design. Sorry about that. Nothing personal. -- Peter Fairbrother. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Thu, Nov 15, 2018 at 11:04 PM Peter Fairbrother <peter@tsto.co.uk> wrote: > On 15/11/18 13:10, Ismail Kizir wrote: > > Hohha Protocol is a quantum safe communication protocol. > > This is the techinal whitepaper draft of our Hohha Messenger which > > we'll publish soon with a MIT Licence. > > Any contribution and or comment will be appreciated. > > Link is a sharable link of a Google Docs document. > > > > https://lnkd.in/gpPXW8n > > Just had a quick look. It's a bit of a hodge-podge, isn't it. But > there's worse: > > 1] The key renewal is worse than useless. If an existing key is not > known to Alice, there is no reason to renew it - if it is known to > Alice, she can deduce the new key. So it's useless. > > It's worse than useless because it introduces complexity and attack > surface. KISS. I don't know of an attack on that part of the protocol > offhand, but why take the chance? > > PSK is an excellent idea. Renew PSK only with the same mechanism as its creation, which means do not renew PSK at all. Any security gain you probably imagined from renewal should come from extension of keylength. If your value proposition is quantum secure message exchange, be generous with the leylength. You are saved from ae already, you have enough space, use it. Taking into account sidechannel defense and implementation hardware/infrastructure you do not have a countious choice space. Focus on the conveniance-security trade-off, more, make calculations and give specific keylength offering based on calculations. > > 2] It uses an untested ?proprietary? roll-your-own algorithm. Ouch. Why > not use something tested? Why allow an untested option, even as an option? > It is OK to propose an algorithm designed specifically for the PSK scheme to be tested. I think everyone here (including Ismail) agrees that a real world implementation should always use a well tested symetric enryption algorithm. > > 3] it can be forced back into using quantum-insecure DH. Ouch. Mallory > will have fun... > The use case of PSK scheme dictates that users use unbreakable passwords and end-point is secure eough. Otherwise, there is no point to take the unconvenaince of the PSK scheme. If a user password or a PSK gets compromised the only solution is physical contact through the same PSK creation mechanism. 4] it places too high a burden on the user. Users are clueless about > security, that's our job, not theirs. > Therefore, the only burden on the user should be physical contact as in case of PSK initialization (creation and sharing) which is user-friendly, though physically inefficient. > > 5] it relies on a trusted server. > It should not as long as the correspondents have a mutual PSK and the protocol sticks to my suggestions above. So, I think PSK scheme is interesting. In fact, I cannot think of another option for an ultimately secure messaging system. I wonder why it is not mainstream, I don't know a messaging system that is PSK based or has PSK option. However, once you have PSK never go below. Once parties bother physical contact for PSK initialization, the rest must be based on a simple protocol which never goes outside the PSK initialization scheme. No online key exchange, no asymetrical encryption, nothing fancy/sexy/complex. Cheers, Ersin _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

> On Nov 21, 2018, at 7:31 AM, Ersin Taskin <hersintaskin@gmail.com> wrote: > > [snip] > So, I think PSK scheme is interesting. In fact, I cannot think of another option for an ultimately secure messaging system. I wonder why it is not mainstream, I don't know a messaging system that is PSK based or has PSK option. However, once you have PSK never go below. Once parties bother physical contact for PSK initialization, the rest must be based on a simple protocol which never goes outside the PSK initialization scheme. No online key exchange, no asymetrical encryption, nothing fancy/sexy/complex. > I disagree that “online key exchange” and “fancy/sexy” schemes “goes below” what PSK offer. As an example, let me refer you to MSL (https://github.com/netflix/msl) and specifically the Authenticated Diffie-Hellman key exchange section thereof (https://github.com/Netflix/msl/wiki/Authenticated-Diffie-Hellman-Key-Exchange). The high level point: Authenticated Diffie-Hellman builds on top of a PSK use case, where both the (Netflix) device and the backend endpoint share the same key. We recognize though, that, with perfect forward secrecy in mind, it is not a particularly good idea to protect any on the wire message with the shared keys, and instead we proceed with a Diffie-Hellman key exchange, followed by further derivation of key material from the computed shared secret, with one of the shared keys. Should the shared set of keys ever be broken, captured past on-the-wire messages would not be decryptable by an attacked, because the attacker could not know the shared secret or anything deriving therefrom. In other words, reusing some of your vocabulary, we start from a PSK situation, but the Authenticated Diffie Hellman scheme allows us to go up from there to add PFS properties. -— Bertrand _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On 21/11/18 22:08, Bertrand Mollinier Toublet wrote: > >> On Nov 21, 2018, at 7:31 AM, Ersin Taskin <hersintaskin@gmail.com> wrote: >> >> [snip] > >> So, I think PSK scheme is interesting. I agree, and not just for use in a postquantum crypto setting. In fact, I cannot think of another option for an ultimately secure messaging system. I wonder why it is not mainstream, I don't know a messaging system that is PSK based or has PSK option. All OTPs are PSK. Len Sassaman used to use an OTP PSK - he would give people DVDs of random key material. Then there is WAP etc,. And so on... There is/was at least one text messaging system which has preshared key exchange on mobiles using bar- and/or QR- codes. Nothing else afaik, the key is simply reused. Can't remember the name offhand, it was used by criminals who got caught and convicted through location tracing and thenceforward required each other to remove batteries from mobile phones when on a mission. However, once you have PSK never go below. Once parties bother physical contact for PSK initialization, the rest must be based on a simple protocol which never goes outside the PSK initialization scheme. No online key exchange, no asymetrical encryption, nothing fancy/sexy/complex. Up to a point, yes. The fancy stuff can frequently make things worse. KISS! > I disagree that “online key exchange” and “fancy/sexy” schemes “goes below” what PSK offer. As an example, let me refer you to MSL (https://github.com/netflix/msl) and specifically the Authenticated Diffie-Hellman key exchange section thereof (https://github.com/Netflix/msl/wiki/Authenticated-Diffie-Hellman-Key-Exchange). > > The high level point: Authenticated Diffie-Hellman builds on top of a PSK use case, where both the (Netflix) device and the backend endpoint share the same key. We recognize though, that, with perfect forward secrecy in mind, it is not a particularly good idea to protect any on the wire message with the shared keys, and instead we proceed with a Diffie-Hellman key exchange, followed by further derivation of key material from the computed shared secret, with one of the shared keys. > > Should the shared set of keys ever be broken, captured past on-the-wire messages would not be decryptable by an attacked, because the attacker could not know the shared secret or anything deriving therefrom. > > > In other words, reusing some of your vocabulary, we start from a PSK situation, but the Authenticated Diffie Hellman scheme allows us to go up from there to add PFS properties. FS is good, and in general I'd use authenticated DH to provide it it in a simple presharedkey app. But the Hohha use-case is post-quantum-resistance, and DH won't provide FS in a Post Quantum setting. For PQ FS in a PSK app we would need some kind of PQ one-way key evolution function. There are several hash- and symmetric- based possibilities. The difficulties are synchronisation and in having to rely on the recipient, as ever. <rant> The proper term is forward secrecy, not perfect forward secrecy. DH can never provide perfect forward secrecy, as it can be broken using quantum computers (or even classical computers if you have enough of them. An OTP can provide perfect forward secrecy - where Alice exists, nothing else can) </rant> -- Peter Fairbrother _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

Bertrand Mollinier Toublet <crypto-metzdowd@bmt-online.org> writes: > In other words, reusing some of your vocabulary, we start from a PSK > situation, but the Authenticated Diffie Hellman scheme allows us to go > up from there to add PFS properties. Yes, this is a good idea. And it is not original. ZRTP supports an "auxsecret" to stir some out-of-band shared key material into the "fancy" Diffie-Hellman negotiation. See https://tools.ietf.org/html/rfc6189#section-4.3 I made a feature request to add something similar to Signal (https://community.signalusers.org/t/3469) but nobody cared - Nemo _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Thu, Nov 22, 2018 at 1:11 AM Bertrand Mollinier Toublet < crypto-metzdowd@bmt-online.org> wrote: > > > On Nov 21, 2018, at 7:31 AM, Ersin Taskin <hersintaskin@gmail.com> > wrote: > > > > [snip] > > > So, I think PSK scheme is interesting. In fact, I cannot think of > another option for an ultimately secure messaging system. I wonder why it > is not mainstream, I don't know a messaging system that is PSK based or has > PSK option. However, once you have PSK never go below. Once parties bother > physical contact for PSK initialization, the rest must be based on a simple > protocol which never goes outside the PSK initialization scheme. No online > key exchange, no asymetrical encryption, nothing fancy/sexy/complex. > > > > I disagree that “online key exchange” and “fancy/sexy” schemes “goes > below” what PSK offer. As an example, let me refer you to MSL ( > https://github.com/netflix/msl) and specifically the Authenticated > Diffie-Hellman key exchange section thereof ( > https://github.com/Netflix/msl/wiki/Authenticated-Diffie-Hellman-Key-Exchange > ). > > The high level point: Authenticated Diffie-Hellman builds on top of a PSK > use case, where both the (Netflix) device and the backend endpoint share > the same key. We recognize though, that, with perfect forward secrecy in > mind, it is not a particularly good idea to protect any on the wire message > with the shared keys, and instead we proceed with a Diffie-Hellman key > exchange, followed by further derivation of key material from the computed > shared secret, with one of the shared keys. > > Should the shared set of keys ever be broken, captured past on-the-wire > messages would not be decryptable by an attacked, because the attacker > could not know the shared secret or anything deriving therefrom. > > > In other words, reusing some of your vocabulary, we start from a PSK > situation, but the Authenticated Diffie Hellman scheme allows us to go up > from there to add PFS properties. > I think u confuse the persistent keys (PSK) with the session keys due to my failure to explain clearly. Remember the context of the above summary paragraph was criticizing the renewal of the PS keys in the Hohha protocol. I say “you are saved from AE already,” not dh. I meant “don’t dictate to renew the persistent keys on-line within some period M or number of messages N”. Thanks for sharing the links, which provide a good solution on the PSK scheme I have in mind to secure the session with pfs. Let me explain my context more clearly to prevent further confusion. We aim an ultimately secure messaging system, which can communicate through any channel (on the Internet) and store its messages anywhere (in the cloud). The only constraint is the communication device. You can only use one mobile device to read and write your messages. I.e. the messages are plain text only at your mobile device screen. So the mobile device to use with the PSK option is always with you like an extension to your body (just like most people:)), unlike the set top box use case you mention. I will not go into the details of mobile device implementation of trusted execution environment at this level. You can imagine a smart phone designed for the PSK option or any mobile phone with extension to fit the scheme. I think this is close to what the Hohha creator(s) has in mind. You create, store and share your PSKs only by your PSK mobile device. You share them only offline requiring physical/proximity contact. This provides the root of trust for message communication in the PSK scheme, I have in mind. Session security can be done via Authenticated Diffie Hellman. Some further clarification: Once the message is received, it is persisted anywhere by the receiver who does not need the session keys to read the message any longer. But this is not the case for the MIM. Session keys are used to secure the communication for long-term persistence against mim. Mim can store communication and wait for long until he can get PS keys. PSK scheme is the persistent keys scheme. It is an alternative to AE not DH. Session key management is another layer built on top. The cloud storage service user credentials must be created, stored and managed independently (in your brain for instance). If they are compromised your data is safe because the attacker needs the relevant PS keys. If for some reason your PS key is compromised which should be extremely difficult and involve physical contact then you have a safety window to secure your cloud service credentials, and once again the communication mim had stored is also safe thanks to adh session key scheme. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On 21/11/18 15:31, Ersin Taskin wrote: > > > On Thu, Nov 15, 2018 at 11:04 PM Peter Fairbrother <peter@tsto.co.uk > <mailto:peter@tsto.co.uk>> wrote: > > On 15/11/18 13:10, Ismail Kizir wrote: > > Hohha Protocol is a quantum safe communication protocol. > > This is the techinal whitepaper draft of our Hohha Messenger which > > we'll publish soon with a MIT Licence. > > Any contribution and or comment will be appreciated. > > Link is a sharable link of a Google Docs document. > > > > https://lnkd.in/gpPXW8n > > Just had a quick look. It's a bit of a hodge-podge, isn't it. But > there's worse: > > 1] The key renewal is worse than useless. If an existing key is not > known to Alice, there is no reason to renew it - if it is known to > Alice, she can deduce the new key. So it's useless. > > It's worse than useless because it introduces complexity and attack > surface. KISS. I don't know of an attack on that part of the protocol > offhand, but why take the chance? > > PSK is an excellent idea. Renew PSK only with the same mechanism as its > creation, which means do not renew PSK at all. That is the point I was making - but it is not what is in the paper. They propose to refresh the key by generating a new key and sending it protected by the old key. Ouch!! Any security gain you "you"? > probably imagined from renewal should come from extension of keylength. I didn't notice anything like that in the paper. Keylength should of course be preset so it doesn't ever have to be extended. Even fairly huge symmetric keylengths take minimal resources under these conditions. so, keylength? To give 128-bit security against Grover's algorithm we would need 256 bits of key. If De Broglie/Bohm is correct (I think it is, but many disagree) we might need 384 bits. We might also need two keys, one for authentication and one for messages, so 768 bits. Round that up to 1k-bit for future-proofing, should be plenty. 1k-bit... if we are not doing DH but just eg xoring random numbers generated alternately by two devices, then key establishment takes negligible resources. Even with DH, key establishment resources are very small. > 2] It uses an untested ?proprietary? roll-your-own algorithm. Ouch. Why > not use something tested? Why allow an untested option, even as an > option? > > It is OK to propose an algorithm designed specifically for the PSK > scheme to be tested. No, it is not OK. Not even vaguely. What are you testing? the algorithm, the scheme, both together? If its the algo, which is not going to be fielded in a real-world implementation, it's a waste of testing resources. If you are testing both together, why?, if you aren't going to be using both together? You aren't testing the final product, when you could be. If you are testing the scheme, wouldn't it be better to use the final algorithm? It's going to be something for which code is readily available, much simpler than coding a roll-your-own. I think everyone here (including Ismail) agrees > that a real world implementation should always use a well tested > symetric enryption algorithm. From what Ismail has told me offlist, I don't think he agrees with that. Certainly in the paper, a roll-your-own cipher is to be used. > 3] it can be forced back into using quantum-insecure DH. Ouch. Mallory > will have fun... > > The use case of PSK scheme dictates that users use unbreakable passwords > and end-point is secure eough. Otherwise, there is no point to take the > unconvenaince of the PSK scheme. If a user password or a PSK gets > compromised the only solution is physical contact through the same PSK > creation mechanism. Yes. But DH fallback is a part of the project in the position paper. > 4] it places too high a burden on the user. Users are clueless about > security, that's our job, not theirs. > > Therefore, the only burden on the user should be physical contact as in > case of PSK initialization (creation and sharing) which is > user-friendly, though physically inefficient. yes. It also has the benefit that the user *has* to do it in order to communicate, and if it is the *only* thing the user has to do then we don't have to worry about the user *not* doing it, or making uninformed and incorrect security decisions - there are no security decisions for him to make :) > 5] it relies on a trusted server. > > It should not as long as the correspondents have a mutual PSK and the > protocol sticks to my suggestions above. It shouldn't, and maybe as described the server is only semi-trusted, I didn't look in detail - but does it need a server at all? Imo, no it doesn't. Piggyback on text, email, voip, whatever. I am a little confused, are you part of this project? If so, why is what you are saying so very different to what is in the position paper? thanks, Peter Fairbrother > Ersin _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Thu, Nov 22, 2018 at 11:46 PM Peter Fairbrother <peter@tsto.co.uk> wrote: > On 21/11/18 15:31, Ersin Taskin wrote: > > > > > > On Thu, Nov 15, 2018 at 11:04 PM Peter Fairbrother <peter@tsto.co.uk > > <mailto:peter@tsto.co.uk>> wrote: > > > > On 15/11/18 13:10, Ismail Kizir wrote: > > > Hohha Protocol is a quantum safe communication protocol. > > > This is the techinal whitepaper draft of our Hohha Messenger which > > > we'll publish soon with a MIT Licence. > > > Any contribution and or comment will be appreciated. > > > Link is a sharable link of a Google Docs document. > > > > > > https://lnkd.in/gpPXW8n > > > > I am a little confused, are you part of this project? If so, why is what > you are saying so very different to what is in the position paper? > > No I am not part of the project and actually I agree with you on most critics. However, I am thankful to Ismail for initiating a discussion for a messaging system based on a PSK scheme. It has been in my to do list that I will never do due to time limitation. I hope this list can help produce a PSK based messaging scheme. I wrote another mail explaining what I had in mind more clearly. The scheme I have in mind is slightly different than Hohha as explained in my response to Bertrand in this thread. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Fri, Nov 23, 2018 at 11:49 PM Peter Fairbrother <peter@tsto.co.uk> wrote: > On 21/11/18 22:08, Bertrand Mollinier Toublet wrote: > > > >> On Nov 21, 2018, at 7:31 AM, Ersin Taskin <hersintaskin@gmail.com> > wrote: > >> > >> [snip] > > > >> So, I think PSK scheme is interesting. > > I agree, and not just for use in a postquantum crypto setting. > > In fact, I cannot think of another option for an ultimately secure > messaging system. I wonder why it is not mainstream, I don't know a > messaging system that is PSK based or has PSK option. > > All OTPs are PSK. > > Len Sassaman used to use an OTP PSK - he would give people DVDs of > random key material. > > Then there is WAP etc,. And so on... > > There is/was at least one text messaging system which has preshared key > exchange on mobiles using bar- and/or QR- codes. Nothing else afaik, the > key is simply reused. > > Can't remember the name offhand, it was used by criminals who got caught > and convicted through location tracing and thenceforward required each > other to remove batteries from mobile phones when on a mission. > Let me repeat my context which is obviously different than Hohha: I think people who are not crypto experts (doctors, students, lawyers, politicians, businessmen, housewives, etc.) have the right to use whatssapp (or telegram, or skype, or yahoo, etc.) in a user-friendly manner and get ultimate security. Let us define it as PQ-Resistant. The system I have in mind should be P2P. It is for the people and run by the people. No different messaging application than the one u use (say whatsapp for all messaging). No need to enter a pin, etc. Mainstream. So the OTP/WAP/2FA/criminal/noname examples you gave do not answer my question. The best I can think of is physical P2P PSK initialization (one PSK per pair of people). Then ADH takes care of the session keys. Simple. > FS is good, and in general I'd use authenticated DH to provide it it in > a simple presharedkey app. > > But the Hohha use-case is post-quantum-resistance, and DH won't provide > FS in a Post Quantum setting. > > For PQ FS in a PSK app we would need some kind of PQ one-way key > evolution function. There are several hash- and symmetric- based > possibilities. The difficulties are synchronisation and in having to > rely on the recipient, as ever. > > <rant> The proper term is forward secrecy, not perfect forward secrecy. > DH can never provide perfect forward secrecy, as it can be broken using > quantum computers (or even classical computers if you have enough of > them. An OTP can provide perfect forward secrecy - where Alice exists, > nothing else can) </rant> > I see we have been thinking the same way and only differ in our context and therefore the threat model. The PSK is compromised via physical contact, and session keys are compromised by mim. Session key randmoness is built on top of PSK randomness. ADH is not PQ resistant, but ADH on PSK is. Therefore, the session is PQ resistant (against its threat model which is mim). PSK threat model and session key (SK) threat model differ significantly. The two corresponding surgeons who ask their asistants to use their laptops for their own work, but are literate enough to use their mobile phone (like most doctors) can communicate securely and easily against the crypto mim because they live in different countries/cities. Mim cannot get their PSK's. All the non-literate users need to know is to keep their devices secure physically by obeying easy to understand rules of thumb. So the sessions are PQ-resistant. If however, a threat model which has close proximity can get the PSK via some physical contact then the sessions are not PQ-resistant but are still pretty safe against the proximity threat (say the house-wife :)). So the scheme relies on the two different and independent nature of threat models to provide a much more secure than available and convenieant messaging scheme for the people. The beauty of ADH is that it can be applied P2P, without the need for 2FA, vendor registration, pinning, etc. Once again the root of trust is PSK which is PQ-r, we use AE/ADH like sexy stuff only for session keys. The more fancy/sexy you go the more sophisticated (vulnerable and/or incoveniant) the system gets. The simplicity of this model helps the security of PSK's. Therefore, the physical contact requirement for the attack is the key foundation of the scheme. The fact that mainstream mail and messaging system vendors (whatsapp, telegram, yahoo, google, microsoft, etc.) do not provide people such a scheme is worth discussing and addressing to me. That is my whole motivation for the above context and scheme. Where do we go from the above initial scheme? I think we should focus on making session keys PQ-r even when PSK's are compromised. For that we have time and wish we have wide adoption on the users in the meantime, because we may need them to become more experienced, informed and eager for the optimal construct. Still this additional construct will mostly like be optional since it will be less conveniant for the user. I would personally love to have the freedom to make some of my whatssapp communication PQ-resistant relying on my physical security habits/performance only and without relying on any vendor/provider. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Thu, Nov 22, 2018 at 04:57:42PM +0000, Peter Fairbrother wrote: > On 21/11/18 22:08, Bertrand Mollinier Toublet wrote: > > > > > On Nov 21, 2018, at 7:31 AM, Ersin Taskin <hersintaskin@gmail.com> wrote: > > > > > > [snip] > > > > > So, I think PSK scheme is interesting. > > I agree, and not just for use in a postquantum crypto setting. > > In fact, I cannot think of another option for an ultimately secure messaging > system. I wonder why it is not mainstream, I don't know a messaging system > that is PSK based or has PSK option. PSK doesn't work with Group Messaging. Initially PSK is fine when the group is created, but what happens when a member leaves? Using your model, every user will have to physically get together to roll over. Large groups are going to be next to impossible to manage in a sustainable way. Same goes for new members joining. Another concern I have with your system is the lack of Forward Secrecy. It's almost 2019... let's not reinvent the mistakes of the past. There are schemes out there that allow for what you're trying to aim for (and more). Learn from them and try to incorporate their ideas into what your project. Alfie -- Alfie John https://www.alfie.wtf _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On Fri, Nov 30, 2018 at 8:44 PM Alfie John <alfie@alfie.wtf> wrote: > PSK doesn't work with Group Messaging. Initially PSK is fine when the > group is created, but what happens when a member leaves? Using your > model, every user will have to physically get together to roll over. > Large groups are going to be next to impossible to manage in a > sustainable way. Same goes for new members joining. PSK or DH doesn't matter for groups. Group messages are encrypted and sent individually to every member, with previously established symmetric key. It may be a result of PSK or DH. If no symmetric key has been set between two users, then, a new DH key exchange starts. The fact that a user joins to a group or a user leaves a group hasn't any side effect on security, since, there isn't any common encryption key for a group. The side effect of this security gain, is the cpu and bandwidth overhead, as you mentioned: If a user is sending a message to a group of 100 persons, he must encrypt 100 times that message with different keys. Group attachments have a separate key and nonce: When Alice sends a group message to Bob, group message text and group message attachment key is encrypted with symmetric key and then sent to Bob. When Bob receives that group message, he decrypts both message text and attachment key with their actual common symmetric key, then downloads the attachment and then decrypts the attachment with attachment key. Consequently, attachments are encrypted only once. I think group message encryption method is enough secure and I don't want to make any modification about this part. For very large groups, in future, for our messenger, we may implement one-to-many plaintext message concept called "Channels". Channel messages will not be encrypted. > Another concern I have with your system is the lack of Forward Secrecy. > It's almost 2019... let's not reinvent the mistakes of the past. There > are schemes out there that allow for what you're trying to aim for (and > more). Learn from them and try to incorporate their ideas into what > your project. After all discussions on this group, I've been convinced to add forward secrecy to protocol. I've sent privately to some members a week ago, but I didn't want to send to group before having updated Whitepaper accordingly. Protocol now imposes HKDF described in RFC 5869 (https://tools.ietf.org/html/rfc5869). And it provides forward secrecy. I updated Whitepaper accordingly and gave credit to group members(including you), who convinced me to add forward secrecy to protocol. Thanks again to all group members who contributed to forward secrecy discussions Ismail Kizir > Alfie > > -- > Alfie John > https://www.alfie.wtf > _______________________________________________ > The cryptography mailing list > cryptography@metzdowd.com > http://www.metzdowd.com/mailman/listinfo/cryptography _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

On 04/12/18 00:22, Ismail Kizir wrote: > After all discussions on this group, I've been convinced to add > forward secrecy to protocol. > I've sent privately to some members a week ago, but I didn't want to > send to group before having updated Whitepaper accordingly. > Protocol now imposes HKDF described in RFC 5869 > (https://tools.ietf.org/html/rfc5869). > And it provides forward secrecy. > I updated Whitepaper accordingly That's Good. Some of the Bad: 1] Still has roll-your-own cipher algorithm. 2] Still has attacker-forcible default to DH, though at least maybe that is now postquantum? I didn't look hard. 3] The hybrid DH protocol is FAR too complicated, and there are probably half-a-dozen holes in it - - eg the MITM measures don't work and don't prove anything: sending lists of messages to resend is asking for trouble, especially as there is no authentication: non-receipt of acknowledgement messages is easy for an attacker to fake, as is stealing or breaking or apparently breaking Bob's phone: and if FS is implemented properly Alice can't resend messages anyway, as she doesn't have the key any more. I assume MK is updated as mentioned in the FS part. 4] Still uses dedicated server. 5] Still too complicated, asks users to make security judgements. Suggested solutions: 1] Remove algorithm choice; use only one well-tested cipher algorithm. 2] and 3] No DH. No real need. 4] Piggyback on some other, preferably encrypted/encryptable, messaging protocol's servers. 5] Just doing the above will simplify it to the point where we can see the wood from the trees. Then we might get some idea of whether it works or not (you didn't think that just doing the above would be enough, did you? :) Peter Fairbrother _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography