[noise] The STROBE lite framework

[Michael Hamburg]

> On Aug 4, 2015, at 5:32 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> 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”.

When you call duplex, you get ciphertext = new state = state ^ plaintext, so the new state is the output.

When you call unduplex, you get (plaintext, new state) = (state ^ ciphertext, ciphertext), so the new state is the input.

(In both cases, of course, the new state also includes the old state’s “capacity” side.)

This is necessary to match the resulting states between the encrypting party and the decrypting party: the new state is the ciphertext, which is the output of the encrypting party and the input of the decrypting party.

The fact that unduplex overwrites the state with zeros is useful for “forgetting”, which is important to achieve forward security if you don’t modify the sponge construction (modify eg by F(r,c) = KeccakF(r,c) xor (0,c), which might allow better standard-model analysis).  You can also use “forgetting” to reduce the state size for an infrequently-used sponge state, by setting the rate part to all zeros.

While it’s not necessary in the random permutation model, there could be an argument for replacing (duplex,unduplex) with a pair of operations that preserve the state’s entropy.  This would mitigate herding and multicollision attacks if keccak turns out to be weak.  In that case, forgetting would have to be a separate operation.

>> 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

Yeah, something like that.

I guess my idea was to have the protocol define thin, possibly static-inline wrappers around absorb/squeeze/duplex/unduplex.  So you would have a GETKEY function which is stroblite_op(sponge_state, TAG_GETKEY, OP_SQUEEZE, output, NULL /* no input */, length) or whatever.

But then if you wanted something other than a key (eg a session hash or sig challenge), or a key with a different purpose, you would make the same call with a different tag.

> 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

Hmm, possibly.  Not sure.  It might depend on whether it makes it easier or harder to drop in new cipher suites.

Cheers,
— Mike