Sequential call of `encrypt`/`dump`/`wrap` with the same cocoon object produces the same cipher text about cocoon HOT 10 CLOSED

@ProjectInitiative I am keen towards moving hardly: mut + version bump to 0.4.0 + rustsec advisory for <0.3.x.

Why:

1. I haven't found evidence that I deliberately planned to have an immutable API, although I found a commit, where the API became to be immutable:
   fa4d1d9.
2. Introducing additional API calls doesn't make the old API more secure for sequential usage.

from cocoon.

Closing issue!

from cocoon.

Created a pull request fixing the issue, and adding some new test criteria to all 4 of the encrypt functions #23

from cocoon.

Also opened an issue here: rust-random/rand#1345

from cocoon.

Wow, nice finding. I left comments in the PR.

from cocoon.

@ProjectInitiative What a nasty issue :) Here's the thing: originally, I designed API to be a one-shot, e.g. you initialize Cocoon, dump something, and leave. On the other side, sequential dumping/encrypting is a nice feature. However, changing the API to be mutable would break backward compatibility.

Options:

1. We could introduce dump_next(&mut self,...), encrypt_next(&mut self, ...).
2. Bumping version to 0.4.0.

from cocoon.

Both are good, I would suggest a contingency on option 1: might be a good idea to add an crate.io advisory for < 3.x.x as I found this out by NOT using the crate in the intended way, and others might have as well while thinking their implementation was correct.

As for which to select? I am not sure, I will defer the direction of the project to project owner.

I will note from a security perspective, option 2 with a crate.io advisory would force/push dependent projects to re-evaluate and confirm the security they expect in their respective projects.

from cocoon.

@ProjectInitiative 0.4.0 is published (https://crates.io/crates/cocoon)

from cocoon.

Security Advisory PR: rustsec/advisory-db#1805

from cocoon.

@ProjectInitiative I just found that it was reproduced with MiniCocoon only and with Cocoon::from_seed (and others with custom RNGs and seeds) where StdRng is used! That's why I haven't found it easily in the first place. It means that cloning ThreadRng (which is used in Cocoon::new) and StdRng (which is used in MiniCocoon and Cocoon::from_seed) behaves differently, or maybe ThreadRng adds entropy every time no matter what.

from cocoon.