[noise] Variable-length handshake payloads?

[Jonas Acres]

Greetings, I hope this is the right place to ask Noise implementation questions.

I am working on a project that uses Noise. We want to:
 1. Exchange payloads during handshaking (i.e. use the payload fields in WriteMessage/ReadMessage),
 2. Ensure that all transmitted bytes are indistinguishable from random noise, and

 3. Have variable-length payloads.

And #3 is where the problem comes in, because it seems to me that the spec indicates that everything in the 'payload' field will be passed to a single call of the EncryptAndHash/DecryptAndHash functions. This appears to require the caller to know the length of the payload in advance to know when they've got the whole ciphertext.

Below is a possible workaround that is a deviation from the spec. Here is what it looks on the write side:

---begin pseudocode---
Let:
  payload be a variable-length byte sequence
  zerolen be a zero-length byte sequence

// encrypt a blank, sort of like in REKEY()
lengthObfuscator = EncryptAndHash(zerolen)

// calculate what the ciphertext length will be for our plaintext payload
ctLength = calculateCiphertextLength( len(payload) )

// xor the first two bytes of the ciphertext with the length
obfuscatedLength = ctLength ^ (lengthObfuscator[0] << 8 | lengthObfuscator[1])

// mix the obfuscated length into the hash, since it will be sent on the wire
MixHash(obfuscatedLength)

// cat the two together to get a modified payload
modifiedPayload = obfuscatedLength || EncryptAndHash(payload)

// the modified payload is what is actually sent on the wire at the end of a message pattern
transmit(modifiedPayload)
---end pseudocode---

This is a deviation from the specification, because we have 1) a two-byte field that is NOT passed to DecryptAndHash by the reader, and 2) an extra call to EncryptAndHash by both parties that does not appear in the spec at all.

My questions are:

1. Is there an established way to do variable-length payloads during handshaking in Noise that I can use instead?
2. If there is not, does this approach make sense, and would it be wrong to claim that we are using Noise if this approach is used?

Thanks,
Jonas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20181212/fb03445e/attachment.html>