[noise] Draft extension: Ephemeral key obfuscation

[Trevor Perrin]

On Mon, May 28, 2018 at 5:18 AM, str4d <str4d at i2pmail.org> wrote:
>
> This is the first of three draft extensions I've been working on, as
> part of designing the new Noise-based TCP transport for I2P [0]. Note
> that I'm using the term "extension" loosely - I don't know exactly how
> these would best fit into the ecosystem.

Hi str4d,

I'm glad you and I2P are considering Noise, thanks for all this input!

I do think these ideas would be good Noise extension documents - we
haven't done a lot with extension docs yet, but we have "spectemplate"
and "spectools" repos for handling them.  The NoiseSocket and NLS
drafts on the wiki are our best current examples.

To your ideas -


> # Noise extension: Ephemeral key obfuscation
[...]
> - aesobfse: Obfuscation using AES256-CBC with a pre-shared key and IV.
>   - Fast, but requires a pre-message pattern for the responder (being
>     the party that needs to successfully decode first).
>   - Compatible with any DH type.
>   - The encoded byte stream is the encryption of the regular encoding of
>     the DH key, with arbitrary (ignored) data appended to round to a
>     multiple of 16 bytes.
>   - No padding mode is applied (so if the key is already a multiple of
>     16 bytes in length, no additional block is appended).
>   - The last ciphertext block of the previous ephemeral in the handshake
>     pattern is used as the IV for the next ephemeral (i.e. treating the
>     ephemerals as a single plaintext stream).
>   - [Meta-note: I'd love to hear alternative suggestions for a fast
>     obfuscation mechanism.]

You raise a lot of interesting points, I'll have to think more about
the Elligator vs symmetric-key approaches.

Like Justin, I'm wondering whether we could accomplish the
symmetric-key approach with a modifier that causes Noise encryption of
ephemeral public keys, just like static public keys.

This modifier would have to be used with a PSK to protect the initial
ephemeral, and we'd have to modify the PSK logic, since currently we
assume PSKs might be reused and require the ephemeral to randomize
them.  (It might not be necessary to add an additional nonce here,
maybe we could assume that in this special case, randomizing the PSK
would be done before passing it in).

If we could work that out, it obviously might be a smaller change then
having a new AES encryption thing...

(Side note: as we consider postquantum KEMs, we'll have to ask
ourselves whether KEM ciphertexts should be encrypted (like static
public keys) or not (like ephemeral public keys).  I'm not sure the
right answer, but if we figure out a way to optionally encrypt
ephemeral public keys, it might be useful there too).

Trevor