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

[Peter Fairbrother]

On 21/11/18 15:31, Ersin Taskin wrote:
> 
> 
> On Thu, Nov 15, 2018 at 11:04 PM Peter Fairbrother <peter at tsto.co.uk 
> <mailto:peter at 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