crypto-common: add SerializableState trait#1369
Conversation
|
I am not sure about the derive crate. It adds a significant amount of code and could be dangerous in respect to serialization output stability. I think we can afford to write serialization by hand on a case-by-case basis? |
|
@rpiasetskyi could you remove the custom derive for now so we can just focus on the core traits? That would help make it easier to review. |
|
@tarcieri sorry for the delay. @newpavlov I would still recommend using it in most cases because it helps to avoid unnecessary code duplication and makes it easy and safe. It works as But some for structures it might be better to implement manually.
Could you please explain your concerns? |
Reordering of fields or changing types (e.g from |
This trait is used for saving the internal state of the object and restoring the object from the serialized state.
|
Going to merge this as it's a frequently requested feature. Since |
|
Is this hazmat? It's well beyond the typical analysis of course. Inherent methods might not be dangerous for specific hash functions, but in general you'd expect serializing the internal state breqaks assumptions when used, or even permits collisions. At least the warning should read stronger: Analysis of cryptographic primitives rarely if ever consideres serialized state, so employing serialized state would typically break the security of the underlying primitive: Serialized state would tyically leak sensitive data. A digest or cipher loses its randomness or collisions resistance properties. We advise that serialized state only be used in non-advarsarial layers of the protocol. |
|
I'd say there's quite a bit of misuse potential. It could definitely use some warnings. We could also gate implementations of the trait under a |
|
Hi, As I'm interested in this feature I started testing the Are there any examples on how to use I wrote this small example using fn main() {
use sha2::digest::crypto_common::SerializableState;
use sha2::Digest;
let mut hasher = sha2::Sha256::new();
hasher.update(b"hello ");
let result = hasher.serialize();
}And the compilation error looks pretty opaque to me: Thanks for help! 👋 |
|
An option, you could give either the trait or its methods scary names, like |
|
@burdges for other things like this we've put it in a We should probably also add documentation about potential misuses to each of the traits as well. |
|
Here's a PR to place all of the traits inside a |
This is a rebase of #385 on master. RustCrypto/traits#1369 introduced a `SerializableState` trait to serialize the hasher. This implements it for each of the hashers we have. Co-authored-by: Ruslan Piasetskyi <ruslan.piasetskyi@esrlabs.com>
|
@wiktor-k I got same compile error. Do you find way to fix it? |
It should be fixed by this PR: RustCrypto/hashes#574 (comment) |
### Added - Sealed `BlockSizes` trait implemented for types from `U1` to `U255` ([#1172]) - `SerializableState` trait under `hazmat` module ([#1369]) - `OutputSize` type alias ([#1533]) - `IvState` trait ([#1636]) - `core::error::Error` impls for error types ([#1660]) - `Generate` trait as a common RNG API ([#2096], [#2145]) - `TryKeyInit` trait ([#2097]) - Re-export `getrandom` ([#2152]) - `KeyExport` trait ([#2213]) ### Changed - Replaced `generic-array` with `hybrid-array` ([#1319], [#1976]) - `BlockUser::BlockSize` is now bounded by the `BlockSizes` trait - Edition changed to 2024 and MSRV bumped to 1.85 ([#1759]) - `generate_*` methods on `KeyInit` and `KeyIvInit` traits have been deprecated in favor of the new `Generate` trait ([#2162]) - Bump `rand_core` to v0.10 ([#2250]) - Bump `getrandom` to v0.4 ([#2258]) ### Removed - `std` feature ([#1680]) [#1172]: #1172 [#1319]: #1319 [#1369]: #1369 [#1533]: #1533 [#1636]: #1636 [#1660]: #1660 [#1680]: #1680 [#1759]: #1759 [#1976]: #1976 [#2096]: #2096 [#2097]: #2097 [#2145]: #2145 [#2152]: #2152 [#2162]: #2162 [#2213]: #2213 [#2250]: #2250 [#2258]: #2258
Trait for saving the internal state of the object and restoring it later.
Original PRs: #1078 #1361
Original issue: RustCrypto/hashes#310