<div dir="auto">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.<div dir="auto"><br></div><div dir="auto">Justin</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 7 Jun 2018, 12:26 Rhys Weatherley, <<a href="mailto:rhys.weatherley@gmail.com" target="_blank" rel="noreferrer">rhys.weatherley@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div><br>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.<br><br>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.<br><br>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.<br><br>A new DH algorithm called "None" is added which only operates with ephemeral keys:<br><br>    DHLEN = 32<br><br>    GENERATE_KEYPAIR(): Generate a random 32-byte value v and then set<br>    k to the first 32 bytes of HASH(v).  Return the pair (k, k) to the<br>    caller for the public and private components (the private component<br>    is essentially useless).<br><br>    DH(key_pair, public_key): Returns an empty byte sequence to the caller,<br><br>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":<br><br>    Noise_NNpsk0_None_ChaChaPoly_BLAKE2s<br>    Noise_NNpsk0_None_AESGCM_SHA256<br><br>Together with the use of PSK's, the "e" token for each party becomes:<br><br>    v = a new random 32-byte value<br>    k = the first 32 bytes of HASH(v)<br>    Append k to the buffer<br>    MixHash(k)<br>    MixKey(k)<br>    discard k and v<br><br>The "ee" token stirs the chaining key state but otherwise does nothing:<br><br>    MixKey(empty)<br><br>An alternative is to simply delete the "ee" token from the pattern when "None" is specified.<br><br>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.<br><br>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.<br><br>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:<br><br>    Noise_NNheresy+psk0_25519_ChaChaPoly_BLAKE2s<br><br>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.<br><br>Possible alternative names for "None": "Nonce" or "Heresy" or "NoWayRhys" :-)<br><br>Thoughts?<br><div><br></div><div>Cheers,</div><div><br></div><div>Rhys.<br></div></div>
_______________________________________________<br>
Noise mailing list<br>
<a href="mailto:Noise@moderncrypto.org" rel="noreferrer noreferrer" target="_blank">Noise@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer noreferrer noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
</blockquote></div>