[noise] The STROBE lite framework

[Trevor Perrin]

On Thu, Jul 30, 2015 at 6:06 PM, Michael Hamburg <mike at shiftleft.org> wrote:
> Hello all,
>
> I’ve been working recently on a protocol framework based on Noise, Keyak and on MJ Saarinen’s BLINKER, but targeted specifically at constrained devices like IoT.  I’d very much appreciate your feedback on the design.

Thanks,

It's interesting how the API from a sponge relates to the Noise APIs:


> In the STROBE lite framework, the two parties with a session maintain matching states for a sponge construction, which is currently Keccak-f[800] with a 256-2-bit capacity and a 544+2-bit rate.  The 2 bits are padding.  Protocols are broken down into ops which have a protocol-defined tag byte, an opcode, and some data.  The opcodes are squeeze, absorb, duplex and unduplex.  Unduplex is like duplex, except that the state becomes the input instead of state^input; this is effectively a Keyak decryption.

I'm not understanding "unduplex".


> Higher-level primitives are special cases of these ops.  For example,
>
> Setting a key is (TAG_SETKEY, absorb, keybytes)
> Setting a nonce or associated data is also absorb.
> Encrypting a message (with no authentication) is (TAG_ENC, duplex, plaintext)
> Decrypting a message is (TAG_ENC, unduplex, ciphertext)
> Sending a MAC is (TAG_MAC, unduplex, [0]*mac_length).  It could also be squeeze, but unduplexing is probably better.
> Checking a MAC is (TAG_MAC, duplex, mac).  If mac_length <= rate, this sets the first mac_length bytes of the state to 0, which you can check.


Noise has high-level APIs for protocol design (descriptors, patterns).
It also has a low-level API for ciphersuites (ENCRYPT, GETKEY, etc).

The Sponge API is sort of in the middle, capturing the idea of a state
object that absorbs secret and nonsecret data and can then be used to
encrypt data, or emit keys:
 - absorb is similar to Noise's updating of h and k
 - squeeze is similar to GETKEY
 - duplex is similar to ENCRYPT / DECRYPT

Noise doesn't separate these state operations into an object with
function calls quite as cleanly.  I wonder - but am not sure - if that
would be a better exposition, or aid reusability.


Trevor