Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
- See https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/122
|
|
- See https://gitlab.com/openpgp-wg/rfc4880bis/-/commit/a42ea9c05479cc8b0424c85b865d796d2250586c
|
|
|
|
|
|
|
|
|
|
- The Galois/Counter mode for block ciphers is a FIPS-approved AEAD
mode. It will be added to the upcoming OpenPGP standard so that
we have a FIPS-compliant subset of OpenPGP.
- Currently, this is only implemented by the Nettle backend.
|
|
- In order to deal with version 2 SEIP packets, we first need to be
explicit about the packet version in the message parser.
- Rename the token and grammar rules, pass in a version to
MessageParser::push.
|
|
|
|
|
|
|
|
- Enable sequoia-openpgp/default by default, notably this enables
support for deflate compression which was missing.
- Expose the compression features.
- Add the OpenSSL and RustCrypto backends.
|
|
- See if we are executing under a tokio async runtime, and if so,
start a new one on a different thread.
- This works around a design problem with the
openpgp::crypto::{Signer, Decryptor} traits that use sync functions,
but our implementation of the traits is async. We used to
unconditionally start a tokio runtime and block to hide the async
nature of the implementation, but that leads to panics if the
current thread is already managed by a tokio runtime. This is a
really easy mistake to make, and is not detected by the type
system.
|
|
|
|
|
|
|
|
|
|
- The main reason to use a `RawCertParser` is to avoid having to
parse certificates that are definitely not needed in the current
context.
- Add some convenient accessor functions to `RawCert`:
`RawCert::primary_key`, `RawCert::keys`, `RawCert::subkeys`, and
`RawCert::UserID` to make this easier.
|
|
- Add `RawCertParser`, which splits keyrings into individual
certificates, similar to `CertParser`, but without invoking the
heavy machinery of the `CertParser`.
- `RawCertParser` uses the OpenPGP framing information to identify
the packets, and it makes sure that the packets form a valid TPK or
TSK as per Sections 11.1 and 11.2 of RFC 4880, respectively.
|
|
- When a packet source returns an error to `CertParser::next`, don't
assume that that means EOF. Subsequent calls may still return
packets.
|
|
- When `CertParser::next` is called and there is a queued error,
return it immediately; don't wait for an EOF.
|
|
- When `CertParser::next` encounters an error reading the next
packet, and then encounters an error creating the queued
certificate, queue the second error, and return the first one.
|
|
- If the `PacketParser` encounters junk (i.e., corruption) and is
able to find a valid packet within `RECOVERY_THRESHOLD` bytes of the
end of the last valid packet, it recovers by converting the junk to
an `Unknown` packet, and continuing to parse.
- Extend this recovery mechanism to junk at the end of the file. If
the `PacketParser` encounters up to `RECOVERY_THRESHOLD` bytes of
junk at the end of the file, convert that data into an `Unknown`
packet instead of immediately returning an error.
- By returning an `Unknown` packet instead of an error, we also
return the last buffered packet, which was otherwise lost.
- When converting `RECOVERY_THRESHOLD` bytes of junk into an
`Unknown` packet, queue an error (in `PacketParserState`) so that
the next call to `PacketParser::next` will not continue trying to
parse the input, but return an unrecoverable error.
- Fixes #967.
|
|
- When pushing a tag using `KeyringValidator::push`, allow
the `Tag::Unknown` and `Tag::Private` variants.
- The grammar already allows them.
|
|
- When tracing is enabled, log what the iterator returned from
`CertParser::From<PacketParserResult>` does.
|
|
- When tracing the execution of a `PacketParser`, don't emit the
`BufferedReader`, as this can result in a huge amount of unreadable
output.
|
|
- Make `PacketParser::plausible_cert` generic over the cookie so
that it is usable with generic `BufferedReader`s.
|
|
- `CertParser::saw_error` is set, but never read. Remove it.
|
|
|
|
|
|
- Change the default buffer size from 8 KB to 32 KB.
- Benchmarking using the chameleon reading a 23 MB cert-d with about
800 certificates, and verifying a signature over a short (2 KB)
message, showed that 32 KB is optimal. In particular, 16 KB and
64 KB buffer sizes were, respectively, 10% and 30% worse.
|
|
- When `buffered_reader::Generic::data_helper` is called and the
amount of data that is requested exceeds the amount of data that
is available, we read from the underlying reader.
- When determining how much to read from the underlying reader, we
took the maximum of the amount requested and the default buffer
size, and then subtracted the amount of data that is available.
- This means that when the amount requested is greater than the
buffer size, we would read exactly the amount requested. This is
problematic for two reasons. First, it is not unusual for a user
of a `BufferedReader` to not consume the data (e.g., a
`buffer_reader::Dup` never consumes data). In that case, once
calls to `BufferedReader::data` request more than the default
buffer size, the `BufferedReader` would forward any reads to the
underlying reader, and append the result to the available data to
create a single continuous `Vec<u8>`. Second, many of these reads
are for just one more byte than is available. The consequence is
that once the amount requested exceeds the amount available, many
subsequent reads would read from the underlying reader, and
`memcpy` the data held by the `BufferedReader`, which destroyed the
performance.
- Avoid most of the reads and the `memcpy`s by changing the behavior
of `buffered_reader::Generic::data_helper` as follows: if the
amount requested exceeds the amount available, try to read the
amount requested plus the buffer size minus what is available.
- Make the same change to `openpgp::armor::Reader`.
- Fixes #969.
Co-authored-by: Justus Winter <justus@sequoia-pgp.org>
|
|
- If the environment variable `SEQUOIA_BUFFERED_READER_BUFFER` is
set, and we are able to parse it as a usize, use it as the default
buffer size.
|
|
These are typos in comments only.
|
|
- This way, only the leaf package has to concern itself with the
selection of a cryptographic backend for Sequoia. Notably, we
don't have to repeat all of sequoia-openpgp's features in all
crates that use sequoia-openpgp.
- Enable the new feature resolver which allows for this method.
- A complication arises because we want to make `cargo test` work by
default for the intermediate crates without developers having to
select a cryptographic backend. To make that work, we implicitly
select a backend in the dev dependencies which are enabled when
compiling the tests. To make it even more convenient, we select
the most convenient backend, which is CNG for Windows and Nettle,
our default, for every other platform.
- Now that we have implicitly selected CNG on Windows for running
the tests, when the user wants to use Nettle on Windows, and does
`cargo test --features sequoia-openpgp/crypto-nettle`, then two
backends are selected: the implicitly selected CNG and the
explicitly selected Nettle. In this case, we detect that an
implicit selection has been made, and ignore the implicitly
selected backend. Now, this has already been compiled by
cargo (remember that we cannot influence the set of dependencies
at the time the build script is run), but we can still ignore the
implicit backend using conditional compilation (i.e. it will not
be included in the resulting binary). The same happens on
non-Windows platforms where Nettle is the implicit default for
tests when the user explicitly requests a different backend. In
both cases, Nettle and CNG are slim wrappers around native
libraries, so the wasted compilation time is low.
|
|
|
|
|
|
- Adds the backend behind `crypto-openssl` feature.
- Add CI configuration to run tests with the new backend.
- See #333.
|
|
- Previously the AEAD roundtrip test checked supported symmetric
ciphers and AEAD algorithms separately but only certain combinations
of them are valid in some libraries.
- See: https://openpgp-wg.gitlab.io/rfc4880bis/#name-preferred-aead-ciphersuites
|
|
- Reversing of Cv25519 compared to X25519 and Ed25519 is a common
source of confusion.
- Add unit tests to check for correct secret key byte order.
|
|
|
|
|
|
- Some backends may want to propagate their internal errors to
the caller.
- Modify all functions to return Results and their clients to
either propagate the error or handle it.
|
|
- Some backends want to verify the AEAD block by themselves and need
the tag to be passed in.
- Change two step `decrypt` + `digest` into a one step `decrypt_verify`.
- Old backends are modified to work like they did previously by
utilizing decryption and the digest operation.
- New backends can implement `decrypt_verify` using their respective
cryptographic primitives.
|