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

Peter Fairbrother peter at tsto.co.uk
Thu Nov 22 11:57:42 EST 2018


On 21/11/18 22:08, Bertrand Mollinier Toublet wrote:
> 
>> On Nov 21, 2018, at 7:31 AM, Ersin Taskin <hersintaskin at 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


More information about the cryptography mailing list