strobe-announce — STROBE version announcements

[Strobe-announce] Announcing strobe-rs

[Michael R. <mi...@fa...>]

Hey everyone. I just wanted to share a project that's now in a semi-polished state. It's a pure Rust implementation of Strobe: https://github.com/doomrobo/strobe-rs <https://github.com/doomrobo/strobe-rs>

I'd be happy to field any question or comments about the implementation. Writing this has been a learning experience.

Some notes on the library:
I was unable to find a Keccak-f[800] or 400 implementation for Rust, so I just stuck with 1600. I hope to contribute some functionality to the tiny_keccak crate in the future.
I've got a few tests that indicate that this agrees with the reference implementation. If you're looking for these tests, they're in a module at the bottom of src/strobe.rs.
I will also be adding functionality to test against the suite of test vectors that David Wong has generously provided in his StrobeGo implementation.

Happy weekend,
Michael

[Strobe-announce] Strobe specification v1.0.2 released

[Mike H. <mi...@sh...>]

After an informal discussion with some folks at NIST, I have found another place where my reading of the cSHAKE specification was incorrect.  In this case, I forgot that the initialization string is a *bit* string, and not a *byte* string, and so the encoding of its length is 8x what I had used.

I have done some minimal coordination with the NIST folks now, so hopefully this is the last such change, but this is yet to be confirmed with a comprehensive test suite.

This specification is now bumped to v1.0.2.  Again, the change is not security-critical, and only affects how STROBE is initialized.

This change is released in commit 0db4bbebe8787b26d18268386339a0fb5a229d3e.

Cheers,
— Mike

[Strobe-announce] STROBE version 1.0.1

[Mike H. <mi...@sh...>]

Welp, that didn’t take long.  And someone is subscribed to the announcement list (welcome!).

Following a discussion with John Kelsey today at RWC, I discovered that the cSHAKE spec (NIST SP 800-185) has changed between draft and release.  This update brings STROBE into line with the released cSHAKE.  Hopefully.  I’m not actually sure, because cSHAKE doesn’t appear to have test vectors yet.

This isn’t a security-related change.  It only affects how STROBE is initialized.

Non-NIST algorithms are required to use the empty string for the NIST part of customization.  The encoding of the empty string in the draft was not well-defined, but was probably best interpreted as [0]. The revised SP 800-185 removes this ambiguity, and sets the encoding as [1,0].

Furthermore, the order of customization strings is now (N,S) instead of (S,N).

So this patch changes the initialization string to contain [1,0] instead of [0], and swaps N with S.  It also bumps the spec version to 1.0.1.

This is released in commit 4eb201b64fe3a834cc44e08c3a928d14d9ef8b41.

The strobe-announce list is moderated.  If you’d like to discuss this release, please do so on strobe-discuss.

Cheers,
— Mike

[Strobe-announce] STROBE v1.0.1 released

[Mike H. <mi...@sh...>]

Welp, that didn’t take long.  And someone is subscribed to the announcement list (welcome!).

Following a discussion with John Kelsey today at RWC, I discovered that the cSHAKE spec (NIST SP 800-185) has changed between draft and release.  This update brings STROBE into line with the released cSHAKE.  Hopefully.  I’m not actually sure, because cSHAKE doesn’t appear to have test vectors yet.

The change only affects how STROBE is initialized.

Non-NIST algorithms are required to use the empty string for the NIST part of customization.  The encoding of the empty string in the draft was not well-defined, but was probably best interpreted as [0].  The revised SP 800-185 removes this ambiguity, and sets the encoding as [1,0].

Furthermore, the order of customization strings is now (N,S) instead of (S,N).

So this patch changes the initialization string to contain [1,0] instead of [0], and swaps N with S.  It also bumps the spec version to 1.0.1.

This is released in commit 4eb201b64fe3a834cc44e08c3a928d14d9ef8b41.

Cheers,
— Mike