| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The main changes that we have to adjust for are as follows:
* In x25519-dalek:
* `StaticSecret` is now behind a feature.
* `StaticSecret::new` is deprecated in favor of
`StaticSecret::random_from_rng`.
* StaticSecret no longer does its own clamping.
* In ed25519-dalek:
* `SecretKey` has (in effect) been renamed to `SigningKey`. The name
`SecretKey` is now an alias for `[u8; 32]`.
* `SigningKey` is effectively a keypair, since it contains a
public key as well.
* `PublicKey` has been renamed to `VerifyingKey`.
* The functions to extract a signing key and verifying key have
been renamed as you might expect.
* `ExpandedSecretKey` has been moved to `hasmat` and no longer
implements `sign`.
* `ExpanededSecretKey` now has as its elements a scalar and a hash
prefix.
* Various functions that took `&[u8]` now take `&[u8; N]`.
* We no longer need a wrapper for older versions of rand.
There is a single test in tor-keymgr that does not pass. I've
marked it as ignore for now, in hopes that @gabi-250 can help me
figure it out.
This closes #808. There are several changes I want to make before
we merge, however. They are marked with TODO DALEK.
|
| |
|
|
|
|
|
|
|
|
| |
Instead of tying ourselves to a particular version of the
generic-array crate, we now always use the version re-exported by
our RustCrypto crates. This lets us avoid the possibility of
version mismatch.
(Originally I had planned to upgrade to generic-array 1.0, but then
I found that we were not actually using it.)
|
| |
|
|
|
| |
Part of #872: Now that const generics are in, we have better ways to
express converting slices into array-references.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Actually, to avoid making a breaking change, I'm deprecating
BadMessage and creating a new InvalidMessage variant that takes a
Cow. This way I don't need to track every crate that re-exposes
tor_bytes::Error and call this a breaking change in those.
Making this change will allow tor_bytes errors to be much more
helpful.
|
| |
|
|
|
|
| |
In addition to the usual "You named that method wrong!" errors, we
have a new rustdoc error that complains about bogus "HTML tags" that
are actually unquoted usage of types like `Result<Foo>`.
|
| | |
|
| | |
|
| |
|
|
| |
(There was only one.)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This comprises four renames:
```
write_onto -> write_onto_infallible
write_into -> write_into_infallible
write -> write_infallible
writer_and_consume -> write_and_consume_infallible.
```
The rest of this branch will be concerned with replacing these
`_infallible` methods with ones that return a `Result`. This is
part of #513.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This crate's Error type is too low-level to have an ErrorKind, but
it does make sense to use InternalError for the internal errors
here.
|
| |
|
|
|
| |
We generally try to track the latest rust-crypto traits when we can:
fortunately, this upgrade didn't break much, considering.
|
| |
|
|
|
|
|
|
| |
We want to only use TODO in the codebase for non-blockers, and open
tickets for anything that is a bigger blocker than a TODO. These
XXXXs seem like definite non-blockers to me.
Part of arti#231.
|
| |
|
|
|
|
|
| |
Also fix a couple of warnings introduced by now-unneeded imports
with new ed25519 crate.
This is part of the process for releasing our next version.
|
| | |
|
| |
|
|
| |
Also fix some commonwealth spellings that had slipped in.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Now that we have const generics, we can use them. We can also avoid
an extra clone in the implementation for [u8; N].
Nothing in our codebase requires that we use Reader or Writer on a
GenericArray holding anything other than u8, so I've switched back
to the more efficient implementation there.
I've added a fuzzer case for the new method, but apparently rustc nightly isn't working too
well with fuzzers for me; I'm going to try it tomorrow.
|
| |
|
|
|
| |
(The nightly version of clippy now includes macros for its
missing_docs_in_private_items lint.)
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
