<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 15, 2018 at 11:04 PM Peter Fairbrother <<a href="mailto:peter@tsto.co.uk">peter@tsto.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 15/11/18 13:10, Ismail Kizir wrote:<br>
> Hohha Protocol is a quantum safe communication protocol.<br>
> This is the techinal whitepaper draft of our Hohha Messenger which<br>
> we'll publish soon with a MIT Licence.<br>
> Any contribution and or comment will be appreciated.<br>
> Link is a sharable link of a Google Docs document.<br>
> <br>
> <a href="https://lnkd.in/gpPXW8n" rel="noreferrer">https://lnkd.in/gpPXW8n</a><br>
<br>
Just had a quick look. It's a bit of a hodge-podge, isn't it. But <br>
there's worse:<br>
<br>
1] The key renewal is worse than useless. If an existing key is not <br>
known to Alice, there is no reason to renew it - if it is known to <br>
Alice, she can deduce the new key. So it's useless.<br>
<br>
It's worse than useless because it introduces complexity and attack <br>
surface. KISS. I don't know of an attack on that part of the protocol <br>
offhand, but why take the chance?<br>
<br></blockquote><div>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.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2] It uses an untested ?proprietary? roll-your-own algorithm. Ouch. Why <br>
not use something tested? Why allow an untested option, even as an option?<br></blockquote><div>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.<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3] it can be forced back into using quantum-insecure DH. Ouch. Mallory <br>
will have fun...<br></blockquote><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4] it places too high a burden on the user. Users are clueless about <br>
security, that's our job, not theirs.<br></blockquote><div>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. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
5] it relies on a trusted server.<br></blockquote><div>It should not as long as the correspondents have a mutual PSK and the protocol sticks to my suggestions above. </div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Ersin<br></div></div></div>