Strobe protocol framework


This spec describes the operation of the Strobe framework. It only covers the symmetric portion. For applications including elliptic curve crypto, see the examples page.

Table of Contents


Definitions and notation


Strobe Instances

Strobe parameters

State of a Strobe object

Initial state

Strobe operations

Low-level operations

AD: Provide associated data

KEY: Provide cipher key

CLR: Send or receive cleartext data

ENC: Send or receive encrypted data

MAC: Send or receive message authentication code

PRF: Extract hash / pseudorandom data

RATCHET: Prevent rollback

Operations and flags

Flags for the defined operations

Composite operations

Implementation of operations

Duplexing and running F


Beginning an operation

Main operation code


This specification describes Strobe version 1.0.2. It has been revised for clarity since that version was released. Special thanks to David Wong for his feedback on the specification.

Definitions and notation

Strobe is useful for building both symmetric cryptosystems and protocols. For simplicity, these are both referred to as "protocols". For example, in an encryption protocol, Alice sends an encrypted and authenticated message to Bob, but Bob does not send any messages back.

Strobe protocols exchange data over some sort of transport. For most protocols

To disambiguate the two parties of a network protocol, Strobe assigns them each a role as an initiator or responder.

Parties start out as undecided, and become an initiator or responder if and when they send or receive a message via the transport.

Strobe operates exclusively on bytes, which are elements of the set [0,...,255]. However, sometimes a length field is required which is larger than one byte. Furthermore, in extensions of Strobe, such as the key tree, we will need elements smaller than one byte. In either case, Strobe follows a little-endian convention.


Variables are formatted like this.

Inline code is formatted like this.

Blocks of code are formatted like this.

Non-normative comments are formatted like this.

Non-normative warnings are formatted like this.

Strobe Instances

There are several paremeters in the Strobe framework. It can use many different rates, permutations and padding modes. These are detailed in the paper. This specification only describes the following recommended instances:

Strobe-128/1600 and Strobe-256/1600 are based on the cSHAKE specification from NIST.

Strobe parameters

Let b be either 400, 800 or 1600. Let F be the function Keccak-f[b]. Let N = b/8. Strobe treats F as a function which takes as input an array of N bytes and returns another array of N bytes.

Let sec be a target security level, either 128 or 256 bits. Strobe has 2*sec bits of secret state. As a result, it is somewhat stronger than a block cipher with sec-bit key. Depending on the exact protocol, it may achieve security comparable to a 2*sec-bit block cipher (as in this paper). In other scenarios — particularly when used as an unkeyed hash — it only has sec bits of security. A future version might add a way to change the rate after a key has been entered.

Let R = N - (2*sec)/8 - 2. This will be the number of bytes in a Strobe block. It is required that 1 ≤ R < 254. This means that b = 400 is incompatible with sec = 256. Obviously R ≥ 1 is required so that Strobe can get any work done at all. The requirement that R ≤ 254 is so that offsets can be represented in one byte. In the existing protocol, this can result in offsets up to R, which would imply that R ≤ 255. The requirement R ≤ 254 is a hedge to allow future modifications. In any case, it is automatically true for any Keccak-based protocol, because R < 1600/8 = 200.

Let X, Y and Z be single digits, representing a major, minor and patch version of Strobe.

The parameters below define the protocol framework called "Strobe-Keccak-sec/b-v1.0.2", which is abbreviated to "Strobe-sec/b". In general, the name would be "Strobe-F-sec/b-vX.Y.Z".

State of a Strobe object

A Strobe object has the following state variables: