You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seeking by a counter value (e.g. NIST SP800-38D) is an exceedingly common operation, whether a stream cipher is a block cipher in counter mode (e.g. AES-CTR), or if a stream cipher uses an underlying block-based construction (ChaCha20, Salsa20). As it were, such seeking is necessary to implement AES-GCM, ChaCha20Poly1305, and XSalsa20Poly1305.
The current SyncStreamCipherSeek trait provides the ability to seek anywhere in the keystream at a byte-level granularity. This complicates the internal buffering logic by requiring stream ciphers to work at non-block-oriented offsets.
I think it'd be nice to have a trait that just accepts a counter value, rather than one which specifies a SeekNum-style byte offset. If we had such a trait, I think we could implement SyncStreamCipherSeek-like behavior in a single place, as opposed to the current state of affairs where internally the chacha20 and salsa20 crates contain copy-pasted code from ctr::Ctr128.
Yes, it seems worth looking into providing more fundamental non-buffering primitives, on top of which will be constructed convenient buffering ones using a generic wrapper similar to BlockBuffer. It should also help with composability (e.g. we can share buffer between MAC function and stream cipher).
I suspect that most users of this crate care about the low-level
`pbkdf2` API as opposed to the higher-level password hashing API which
implements the PHC string format.
The `simple` API pulls in quite a few dependencies (to the point I'm
encountering dependency conflicts).
Seeking by a counter value (e.g. NIST SP800-38D) is an exceedingly common operation, whether a stream cipher is a block cipher in counter mode (e.g. AES-CTR), or if a stream cipher uses an underlying block-based construction (ChaCha20, Salsa20). As it were, such seeking is necessary to implement AES-GCM, ChaCha20Poly1305, and XSalsa20Poly1305.
The current
SyncStreamCipherSeek
trait provides the ability to seek anywhere in the keystream at a byte-level granularity. This complicates the internal buffering logic by requiring stream ciphers to work at non-block-oriented offsets.I think it'd be nice to have a trait that just accepts a counter value, rather than one which specifies a
SeekNum
-style byte offset. If we had such a trait, I think we could implementSyncStreamCipherSeek
-like behavior in a single place, as opposed to the current state of affairs where internally thechacha20
andsalsa20
crates contain copy-pasted code fromctr::Ctr128
.cc @newpavlov
The text was updated successfully, but these errors were encountered: