[Cryptography] Hohha quantum resistant end-to-end encryption protocol draft

[Ismail Kizir]

On Fri, Nov 30, 2018 at 8:44 PM Alfie John <alfie at 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 at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography