[noise] Draft extension: Ephemeral key obfuscation

[str4d]

On 05/28/2018 10:53 PM, Justin Cormack wrote:
> This kind of seems complicated, and IV reuse would be a problem?

I'm probably not describing it well; it doesn't end up particularly
complex to implement (just plain AES-CBC encryption and decryption, with
obfuscator_state storing the last seen ciphertext block as the next IV).

IV reuse also isn't a concern here AFAICT, because the goal is not
encryption, but obfuscation. In an Elligator-like encoding, if you reuse
an ephemeral key you'll get the same obfuscated output. Similarly here,
reusing an ephemeral key with a reused IV would result in a repeated
ciphertext, which is fine in this context. In fact, in our current
design the key is fixed per-responder for their lifetime, and the IV is
fixed per-responder on a medium timescale (because when rotating, the
responder would need to test both old and new IVs against incoming
connections for some period).

The primary (and I think only?) disadvantage to using AES-CBC for
obfuscation instead of Elligator is that with the latter, every (say)
32-byte random byte sequence can be decoded to a valid curve point. For
AES-CBC, the adversary could in the worst case brute-force the key / IV
(or more likely obtain candidates from some oracle), and then check
whether the decrypted data encodes a valid curve point or not. I don't
see a way to avoid this trade-off in exchange for the significant speed
advantages over Elligator-like encodings. I'm also not (yet) convinced
this is a practical issue; if an adversary possesses an oracle for
providing candidate key / IV pairs (by e.g. scraping the DHT where
router connection info is stored), then a much simpler heuristic (the
port) can be used to determine whether a connection matches the protocol.

> 
> On 28 May 2018 at 06:18, str4d <str4d at i2pmail.org> wrote:
>> - 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.]
> 
> Why not something along the lines of (a) require use of a Noise
> pattern with a psk0,
> (b) add an eg 32 bit nonce token which sends a nonce that random, and
> indistinguishable
> from noise, then (c) this then allows e to be encrypted via an extra
> flag in state. I think
> something along these lines might work, using the same encryption
> primitives? Currently
> psk encryption uses e as the nonce but an explicit random nonce in the
> transport stream
> should work as well if you enforce psk, nonce, e, ... as the ordering.

My understanding of psk in Noise was that it is intended to be a secret
known only to a specific (initiator, responder) pair. That precludes the
use case where the initiator looks up the connection info for the
responder in e.g. a public DHT (requiring psk0 to be a public value used
by all initiators). If my understanding is incorrect, then this would
definitely be an interesting alternative proposal (at the cost of extra
bytes per handshake message for the additional per-ephemeral nonce).

Cheers,
str4d

> 
> Justin
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180528/00dbc095/attachment.sig>