SyncStreamCipherSeek::seek overflow behavior not documented about stream-ciphers HOT 6 CLOSED

It's a block counter. The seek() parameter is a byte offset.

from stream-ciphers.

The most straightforward approach will be to add try_seek method and define seek in a similar way to apply_keystream.

from stream-ciphers.

Perhaps the seekable range should be represented by an associated type. That could be used to eliminate the possibility of overflow, and therefore the runtime errors.

from stream-ciphers.

I'm not sure about "eliminate"; that u38 has to come from somewhere 😄

from stream-ciphers.

IETF ChaCha20 uses a 32-bit counter (reduced from 64-bits in the original construction). See RFC 7539 section 2.4 (the counter is used as word 12 of the ChaCha20 input array).

As it were, there's a discussion of how to handle counter wrapping/overflow going on right now on the CFRG:

https://mailarchive.ietf.org/arch/browse/cfrg/?gbt=1&index=gsOnTJzcbgG6OqD8Sc0GO5aR_tU

Perhaps you were suggesting modifying the nonce when the counter overflows? One of the CFRG chairs, Kenny Patterson, explicitly recommends against that:

If you really must wrap blockcounter then I'd argue that it should be done without touching the nonce. The reason is that this new nonce (created by incrementing the existing nonce or whatever) could legitimately be used in a different ChaCha instance under the same key, and your code may have no control over what blocknumbers would be used with that nonce value, thereby increasing the risk of reuse of (blockcounter,nonce) pairs. But you'd still need checks to make sure there were no blockcounter repeats if you just wrapped without touching the nonce. Hence better to start low and disallow wraps (which is after all just such a check!).

from stream-ciphers.

Aha! Well then, that's what I get for responding to crypto emails before I've had my coffee.

So here's a question: should the seeking granularity, from the perspective of the underlying primitive, be based on a block counter instead of a byte offset? While that doesn't align with the typical definition of a stream cipher, I'd be curious to know if there are any cases where a stream cipher is seekable and yet doesn't act on a block counter-oriented API.

That sounds like an API better suited to the ctr crate, but I imagine most seekable block ciphers would fit into that sort of framework.

Back to @kazcw's original point: I'd agree overflow should return some kind of error, and a Result-oriented API is a good idea.

from stream-ciphers.