-
Notifications
You must be signed in to change notification settings - Fork 198
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 <[email protected]>
@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) |
Trait for saving the internal state of the object and restoring it later.
Original PRs: #1078 #1361
Original issue: RustCrypto/hashes#310