Daiki Ueno authored Mar 28, 2025 and Justus Winter committed Apr 01, 2025

This removes unnecessary `.as_ref()` calls in the
x25519-dalek/ed25519-dalek usage

Signed-off-by: Daiki Ueno <dueno@redhat.com>

Daiki Ueno authored Mar 28, 2025 and Justus Winter committed Apr 01, 2025

Signed-off-by: Daiki Ueno <dueno@redhat.com>

Daiki Ueno authored Mar 28, 2025 and Justus Winter committed Apr 01, 2025

Signed-off-by: Daiki Ueno <dueno@redhat.com>

  - See #1161.

  - See #1161.

  - See #1161.

  - See #1161.

  - See #1161.

  - This way the compiler will point us to this match when adding new
    algorithms.

Guillem Jover authored Apr 08, 2025 and Justus Winter committed Apr 24, 2025

These files contain OpenPGP data, and are not vendor specific, so naming
them with an extension after GnuPG creates a lock-in in detriment to the
other multiple OpenPGP implementations, including the Sequoia-PGP one.

Use the vendor neutral .pgp filename extension instead.

Daiki Ueno authored Apr 21, 2025 and Justus Winter committed Apr 25, 2025

Signed-off-by: Daiki Ueno <dueno@redhat.com>

Daiki Ueno authored Apr 21, 2025 and Justus Winter committed Apr 25, 2025

Signed-off-by: Daiki Ueno <dueno@redhat.com>

Daiki Ueno authored Apr 24, 2025 and Justus Winter committed Apr 25, 2025

This adds a new example, "ipc-standalone", which exercises service
invocation through the IPC mechanism. The executable can either be
launched as a standalone server or a client with the --client
option, which may internally spawn the server if it's not running.

Signed-off-by: Daiki Ueno <dueno@redhat.com>

  - Also, avoid some buffered_reader::Generics.

  - Also, avoid some buffered_reader::Generics.

  - Botan's CBC mode doesn't appreciate that.

  - Introduce a new internal interface for symmetric cryptography.
    The new interface is specified by a trait that is implemented by
    the backend, so it is less ad-hoc than the previous interface.

  - Use 3DES, not DES, when ECB mode is selected.

  - Rename, and make it consume the encryptor.

  - Some modes may be compiled in, but disabled at runtime, for
    example by putting OpenSSL into FIPS mode on Fedora and RedHat
    systems.  This mirrors what we do for symmetric algorithms.

  - The error message was right, the check was wrong: unknown S2K
    objects may use one tag byte but no parameters, so the lower bound
    for S2K objects is in fact one octet, not two.

  - This now considers AEADAlgorithm::is_supported, which may do
    runtime checks for the algorithms.

  - Fixes #1191.

  - Fixes e8056f24.

  - Fixes b341fcef.

  - Since 0.7.0, twofish::Twofish implements Clone, so we can use it
    with the AEAD modes.

  - Simplify code accordingly, fixes warnings in the Botan backend.

  - The comments and test vector names previously said that the test
    vectors are encrypted with keys ascending from 0, i.e. [0, 1, ..,
    key.len() - 1].  But, that was not correct.

  - Instead, the keys are [key.len() - 1, 0, 0, ...].  That must have
    happened during development of the code and test vectors, and they
    haven't changed since.

  - Update comments and test vector names to reflect that.

  - Actually return the error we claim to return if the backend
    doesn't support the algorithm.

  - Previously, we used the streaming AEAD encryptor and decryptor to
    write a single chunk, and then the final tag that chunking
    requires to protect against truncation attacks.

  - Since we don't use chunking, we can simplify this a lot.  First,
    we don't have to use the complicated streaming interface.  Second,
    as we no longer write and check the final tag, we save one AEAD
    algorithm invocation per access.

  - Fixes #928.

  - Fix the Nettle backend to correctly report whether the library
    supports OCB.

  - When decrypting a PKESK, fail early if we know we won't be able
    to decrypt the SEIP packet.  In particular, since SEIPv2 packets
    expose the symmetric algorithm and the AEAD algorithm, we can
    check that the crypto backend supports them before decrypting
    the PKESK.

  - This also improves usability, because we return a more accurate
    error message.  When we decrypt a PKESK, we use the decrypted
    session key to decrypt the first bit of the SEIP packet to check
    that the session key is valid.  If the crypto backend doesn't
    support the required algorithms, this fails.  To avoid creating an
    oracle, this function returns a generic error.  Checking earlier
    that the used algorithms are supported means we can return the
    actual error.

  - When decoding PKCS5 padding, check that the amount of padding does
    not exceed the size of the buffer.

  - If the amount of padding was larger than the buffer, this would
    lead to a panic, and could be used by an attacker to cause a
    denial of service.

  - With PKCS5 padding, 0 bytes padding is not possible.  If the
    indicated padding is 0 bytes, return an error.

  - This is unlikely a problem in practice as the invalid result would
    likely cause an error later on.

  - Don't assert that 3DES is supported, it is no longer MTI.

  - Fix this by fixing OnePassSig::try_from for v3 signatures.

  - Fixes #1197.

  - The `aes_key_unwrap` function would panic if passed a ciphertext
    that was too short.  In a debug build, it would panic due to a
    subtraction underflow.  In a release build, it would use the small
    negative quantity to allocate a vector.  Since the allocator
    expects an unsigned quantity, the negative value would be
    interpreted as a huge allocation.  The allocator would then fail
    to allocate the memory and panic.

    An attacker could trigger this panic by sending a victim an
    encrypted message whose PKESK or SKESK packet has been specially
    modified.  When the victim decrypts the message, the program would
    crash.

  - Fix it.

  - Reported-by: Jan Różański.

  - We should only claim that an algorithm is supported if it is
    actually usable in practice.  For hash algorithms, this means that
    `HashAlgorithm::digest_size` can't return an error.

  - Fix the hash and AEAD implementations to only claim that an
    algorithm is supported if the hash is usable.

  - In `StandardPolicy::key`, we `use AsymmetricAlgorithm::*` and `use
    PublicKeyAlgorithm::*`.  As the names of the variants are similar,
    and may conflict in the future, don't import both enums' variants.
    Instead, only import `PublicKeyAlgorithm`'s variants.

  - `EdDSA` (i.e., v4 Ed25519) maps to the same policy as `Cv25519`.

  - This appears to be a cut and paste bug.

  - Add a separate policy for `EdDSA`.

  - See #1225.

  - `EdDSA` (i.e., v4 Ed25519) maps to the same policy as `Cv25519`.

  - This appears to be a cut and paste bug.

  - Fix it.

  - Fixes #1225.

Paul Wekesa authored Sep 19, 2025 and Neal H. Walfield committed Nov 10, 2025

  - `rustc` has started warning about some elided lifetimes.

    ```
    warning: hiding a lifetime that's elided elsewhere is confusing
       --> openpgp/src/crypto/mod.rs:289:26
        |
    289 | pub(crate) fn pad(value: &[u8], to: usize) -> Result<Cow<[u8]>>
        |                          ^^^^^                       --------- the same lifetime is hidden here
        |                          |
        |                          the lifetime is elided here
        |
        = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
        = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
    help: use `'_` for type paths
        |
    289 | pub(crate) fn pad(value: &[u8], to: usize) -> Result<Cow<'_, [u8]>>
        |                                                          +++
    ```

  - Fix some of the warnings.

Signed-off-by: Paul Wekesa <paul1tw1@gmail.com>

  - Cargo version 1.84 added an MSRV aware resolved.

    https://blog.rust-lang.org/2025/01/09/Rust-1.84.0/#cargo-considers-rust-versions-for-dependency-version-selection

  - Use this, when a new enough version of cargo is used.