[noise] Heresy: PSK-only Noise

[Justin Cormack]

I think this will change... I looked at the ESP32 hardware encryption
support briefly and it appears to support hardware designed for EC
calculations. I was planning to investigate further soon... Hopefully this
type of support will appear soon in other devices.

Justin


On Thu, 7 Jun 2018, 12:26 Rhys Weatherley, <rhys.weatherley at gmail.com>
wrote:

> I've done a lot with Arduino-based embedded devices and my Arduino
> Cryptography Library.  I'm currently working on Noise and NoiseLink for
> such devices.  Early days yet - it will take some time to come to fruition.
>
> In the low end space, it is common for devices to lack sufficient memory
> or CPU resources to implement DH functions like Curve25519.  Symmetric
> crypto and PSK's are fine, but DH is too resource-intensive.  ARM devices
> can usually handle it, but AVR devices no.
>
> This begs the question: What is the best way to encrypt packets when
> resource limitations preclude the use of public key cryptography?  People
> who have used my library invariably invent some scheme using CBC mode and
> shared secrets.  Usually by directly encrypting with the shared secret
> itself, which is very bad.
>
> It would be nice if I could recommend something better than "roll your
> own" and perhaps include it in my library.  So, here is a heretical
> proposal for a PSK-only encryption scheme that works within the Noise
> framework.
>
> A new DH algorithm called "None" is added which only operates with
> ephemeral keys:
>
>     DHLEN = 32
>
>     GENERATE_KEYPAIR(): Generate a random 32-byte value v and then set
>     k to the first 32 bytes of HASH(v).  Return the pair (k, k) to the
>     caller for the public and private components (the private component
>     is essentially useless).
>
>     DH(key_pair, public_key): Returns an empty byte sequence to the caller,
>
> The "None" algorithm must be used with PSK-based patterns and the "psk"
> token must appear in the pattern before the first "e" token.  Given that
> "None" does not support static keys, the only pattern of interest is
> "NNpsk0":
>
>     Noise_NNpsk0_None_ChaChaPoly_BLAKE2s
>     Noise_NNpsk0_None_AESGCM_SHA256
>
> Together with the use of PSK's, the "e" token for each party becomes:
>
>     v = a new random 32-byte value
>     k = the first 32 bytes of HASH(v)
>     Append k to the buffer
>     MixHash(k)
>     MixKey(k)
>     discard k and v
>
> The "ee" token stirs the chaining key state but otherwise does nothing:
>
>     MixKey(empty)
>
> An alternative is to simply delete the "ee" token from the pattern when
> "None" is specified.
>
> Technically the HASH(v) step is not required, but it provides some
> protection against poorly implemented RNG's or hardware RNG's that may have
> been backdoored by the CPU manufacturer.  The raw RNG output is hashed
> again to destroy watermarks or low-entropy patterns in "v".  There's no way
> for the receiver to verify that HASH(v) has been done however.  If the
> implementer knows that the underlying RNG is already hashing away
> watermarks, then the HASH(v) step can be omitted.
>
> The "ephemeral keys" act as nonces to randomize the keys in each new
> session.  If one of the parties has a poor random number generator, then
> the randomness from the other party will have to pick up the slack.  In
> embedded environments, one party is often a desktop or smartphone client or
> a phone-home server with a full desktop-level RNG.  Peer-to-peer sessions
> between devices may be a problem unless one of them has a hardware RNG.
>
> I also considered introducing a "n" token for generating nonces and then
> use a pattern modifier to replace "e" and "ee" tokens.  That leads to odd
> names:
>
>     Noise_NNheresy+psk0_25519_ChaChaPoly_BLAKE2s
>
> With a modifier, we still need a real DH algorithm name, but the algorithm
> is effectively erased by the modifier.  Introducing a new DH name was
> cleaner.
>
> Possible alternative names for "None": "Nonce" or "Heresy" or "NoWayRhys"
> :-)
>
> Thoughts?
>
> Cheers,
>
> Rhys.
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180607/757c90c9/attachment.html>