This is version 1.0.2 of the Strobe specification. The software is in alpha.
meta_RATCHET. Still v1.0.2, since it's just a usage
hint.[0]. The final version
changed it to [1,0] with N preceding S.
I'm still not sure I got it right because there are no test vectors.The Internet of Things (IoT) promises ubiquitous, cheap, connected devices. Unfortunately, most of these devices are hastily developed and will never receive code updates. Part of the IoT's security problem is cryptographic, but established cryptographic solutions seem too heavy or too inflexible to adapt to new use cases.
Strobe is a new framework for cryptographic protocols. It can also be used for regular encryption. Its goals are to make cryptographic protocols much simpler to develop, deploy and analyze; and to fit into even tiny IoT devices. To that end, it uses only one block function — Keccak-f — to encrypt and authenticate messages.
Flexibility is an important goal of Strobe. It isn't just a replacement for TLS. I specifically designed it to support a wide variety of protocol building blocks: authenticated DH or FHMQV, signatures, password-authenticated key exchange, DPA-resistant key diversification, ratcheting for forward secrecy, and steganographic connections with length hiding.
Performance is a secondary goal. Strobe is based on SHA-3, or rather Keccak-f and cSHAKE (draft NIST SP 800-185). SHA-3 is a very conservative design. It doesn't yet have acceleration on most CPUs, and it isn't the fastest algorithm around. That said, Strobe is generic and could be rebuilt around a faster permutation once one appears.
Any framework has some rails. Strobe's main rails are around message flow. As a protocol framework, it isn't designed to handle unreliable or out-of-order message delivery. It can still be used as an authenticated cipher, hash function, key derivation function etc. in these protocols.
Strobe isn't inherently nonce-misuse resistant. However, it can be used in an SIV construction to add this property.