Implement embedded GPG-compatible cryptography for existing keys #4

Closed
opened 2026-08-09 18:54:53 +00:00 by hugo · 1 comment
Owner

Objective

Provide embedded GPG-compatible encryption, decryption, signing and key resolution using existing key material.

Scope

  • Import supported ASCII-armored and binary public and encrypted secret keys without launching GnuPG.
  • Resolve configured key identities and .gpg-id recipients by full fingerprint, key ID, or exact user ID with ambiguity errors.
  • Encrypt for one or many recipients and decrypt existing pass .gpg files.
  • Unlock protected secret keys through a secret-provider interface and wipe transient passphrases and plaintext buffers.
  • Sign and verify .gpg-id data required by PASSWORD_STORE_SIGNING_KEY compatibility.
  • Select and document the crypto crate/backend and its license obligations before adding the dependency.

Acceptance criteria

  • GnuPG decrypts IronStorage output and IronStorage decrypts all milestone fixtures generated by GnuPG.
  • Tests cover protected keys, wrong passphrases, missing recipients, ambiguous identities, corrupt packets, signatures, and multiple recipients.
  • No external process, unsafe project code, or real user keyring is required.

Prerequisites

Compatibility fixture harness; safe password-store core.

## Objective Provide embedded GPG-compatible encryption, decryption, signing and key resolution using existing key material. ## Scope - Import supported ASCII-armored and binary public and encrypted secret keys without launching GnuPG. - Resolve configured key identities and `.gpg-id` recipients by full fingerprint, key ID, or exact user ID with ambiguity errors. - Encrypt for one or many recipients and decrypt existing pass `.gpg` files. - Unlock protected secret keys through a secret-provider interface and wipe transient passphrases and plaintext buffers. - Sign and verify `.gpg-id` data required by `PASSWORD_STORE_SIGNING_KEY` compatibility. - Select and document the crypto crate/backend and its license obligations before adding the dependency. ## Acceptance criteria - GnuPG decrypts IronStorage output and IronStorage decrypts all milestone fixtures generated by GnuPG. - Tests cover protected keys, wrong passphrases, missing recipients, ambiguous identities, corrupt packets, signatures, and multiple recipients. - No external process, unsafe project code, or real user keyring is required. ## Prerequisites Compatibility fixture harness; safe password-store core.
hugo added this to the 01 - Full Rust pass CLI parity milestone 2026-08-09 18:54:53 +00:00
hugo added the enhancement label 2026-08-09 18:54:53 +00:00
Author
Owner

Implemented and pushed in 08bc244 (Implement embedded OpenPGP compatibility (#4)).

Implementation:

  • Added a pure-Rust pgp 0.20 backend with default features disabled; no GnuPG, pass, keyring, helper process, FFI, or unsafe project code.
  • Added transactional armored/binary public and protected-secret key import with binding verification, bounded inputs, duplicate merging, exact fingerprint/key-ID/user-ID resolution, ambiguity errors, and pass-compatible .gpg-id parsing.
  • Added uncompressed AES-256 SEIPD-v1 encryption for one or many recipients and decryption of existing pass entries through a redacted, zeroizing SecretProvider boundary. Multi-recipient decryption skips unavailable identities and cancellation remains explicit.
  • Added SHA-256 detached signing and trust-restricted verification for .gpg-id.sig / PASSWORD_STORE_SIGNING_KEY behavior.
  • Documented backend selection, license, packet profile, secret lifetime, and compatibility evidence in docs/cryptography.md and DEPENDENCIES.md.

Issue-isolated verification:

  • cargo test -p ironstorage --test crypto_compatibility: 8 passed
  • Covers protected and wrong passphrases, unavailable/cancelled providers, missing recipients/keys, exact ambiguity, corrupt key/message/signature packets, checked-in signatures, fresh signatures, and single/multi-recipient encryption.
  • IronStorage decrypted every checked-in GnuPG-audited milestone entry. Fresh KeyStore output was independently parsed and decrypted with both protected recipient keys.

Required repository gates all passed:

  • cargo fmt --all -- --check
  • RUSTFLAGS=-D warnings cargo check --workspace --all-targets
  • cargo clippy --workspace --all-targets -- -D warnings
  • cargo test --workspace
Implemented and pushed in 08bc244 (Implement embedded OpenPGP compatibility (#4)). Implementation: - Added a pure-Rust pgp 0.20 backend with default features disabled; no GnuPG, pass, keyring, helper process, FFI, or unsafe project code. - Added transactional armored/binary public and protected-secret key import with binding verification, bounded inputs, duplicate merging, exact fingerprint/key-ID/user-ID resolution, ambiguity errors, and pass-compatible .gpg-id parsing. - Added uncompressed AES-256 SEIPD-v1 encryption for one or many recipients and decryption of existing pass entries through a redacted, zeroizing SecretProvider boundary. Multi-recipient decryption skips unavailable identities and cancellation remains explicit. - Added SHA-256 detached signing and trust-restricted verification for .gpg-id.sig / PASSWORD_STORE_SIGNING_KEY behavior. - Documented backend selection, license, packet profile, secret lifetime, and compatibility evidence in docs/cryptography.md and DEPENDENCIES.md. Issue-isolated verification: - cargo test -p ironstorage --test crypto_compatibility: 8 passed - Covers protected and wrong passphrases, unavailable/cancelled providers, missing recipients/keys, exact ambiguity, corrupt key/message/signature packets, checked-in signatures, fresh signatures, and single/multi-recipient encryption. - IronStorage decrypted every checked-in GnuPG-audited milestone entry. Fresh KeyStore output was independently parsed and decrypted with both protected recipient keys. Required repository gates all passed: - cargo fmt --all -- --check - RUSTFLAGS=-D warnings cargo check --workspace --all-targets - cargo clippy --workspace --all-targets -- -D warnings - cargo test --workspace
hugo closed this issue 2026-08-09 22:00:27 +00:00
Sign in to join this conversation.