If a `LamportSignatureData` object with too few subvectors was passed to the old
code, it would panic when `offset` grew bigger than the number of subvectors.
Obviously, panicing is much better behaviour than what we'd get in other
languages (thanks Rust), but still not ideal.
- If `one_values: Vec<Vec<u8>>` is different in `len()` than `zero_values`, the
code can either panic, or it's possible different `PrivateKey`s are evaluated
as equal. In both these examples, at least one key would be of invalid
structure, but there's nothing about the `PrivateKey` struct that enforces
valid structure in this sense. Perhaps this is an argument to create
key-length-specific types*.
- Algorithm equality is now checked.
* E.g.,
```rust
pub struct PrivateKey512 {
zero_values: [[u8; 512 / 8]; 512],
one_values: [[u8; 512 / 8]; 512],
// ...
}
```
The docstring says this is the intended behavior. The only way a `Vec<u8>`
shouldn't be simply parsed into a `PublicKey` is if it's length is not as
expected for the `algorithm` specified.
*ring* 0.9.3 is the first version that prevents multiple versions of
*ring* from being linked together. Soon *ring* 0.9.3 will be the oldest
version of *ring* on crates.io. *ring* 0.6.* have already been yanked.
