Goal

Provide each SimpleLogin reverse alias with its own independent OpenPGP identity, while keeping key management simple and preventing external observers from linking different aliases to the same Proton account.

Design

Proton maintains a dedicated secret AliasPGPRoot for the user.

For every immutable reverse alias, Proton derives deterministic key material from:

AliasPGPRoot + normalized alias address

using a cryptographic KDF such as HKDF.

Example:

AliasPGPRoot
    |
    +-- HKDF("alias-a@simplelogin.com")
    |       -> OpenPGP key A
    |
    +-- HKDF("alias-b@simplelogin.com")
    |       -> OpenPGP key B
    |
    +-- HKDF("alias-c@simplelogin.com")
            -> OpenPGP key C

Separate derivation contexts should be used for signing and encryption keys.

The resulting OpenPGP certificates are completely independent. They contain only the reverse alias as their identity and no reference to the user's real Proton address, root secret, or other aliases.

The public key for each alias is stored in SimpleLogin. The private key does not need to be stored separately: Proton clients can deterministically reconstruct it locally when needed.

Privacy Properties

An external observer seeing:

alias A -> public key A
alias B -> public key B
alias C -> public key C

should have no cryptographic way to determine that these keys originate from the same Proton account.

Compromise of one derived alias private key should also not allow derivation of the root secret or keys belonging to other aliases.

Architecture

Encrypted AliasPGPRoot
        |
        v
 Proton client
        |
        +-- Alias address
        |
       HKDF
      /    \
 signing   encryption
  seed *     seed
      \      /
   Independent
   OpenPGP key
        |
   Public certificate
        |
    SimpleLogin

* optional
Private alias keys can therefore be generated on demand and discarded after use.

Important Design Requirements

• Use a strong domain-separated KDF such as HKDF.
• Derive signing and encryption key material independently (optional).
• Prefer deterministic ECC-based key generation rather than deterministic RSA generation.
• Alias OpenPGP certificates must not contain metadata linking them to the Proton account or other aliases.
• The alias address must be canonicalized consistently before derivation.
• The derivation format must be versioned, e.g. proton-reverse-pgp/v1, so future algorithms can be introduced safely.

Risks and Considerations

Root-secret compromise:
Compromise of AliasPGPRoot exposes all alias keys. It therefore needs the same level of protection as other high-value Proton secrets.

Deterministic derivation stability:
Changing the KDF, canonicalization rules, curve, or OpenPGP key-generation procedure would otherwise produce different keys. The derivation specification therefore needs strict versioning and long-term compatibility.

Alias reuse:
If a deleted alias address could ever be reassigned, address-only derivation would reproduce the same key for the same user. Ideally SimpleLogin should guarantee that reverse aliases are never reused, or an immutable alias identifier should additionally be included in the derivation.

Metadata correlation:
The scheme prevents cryptographic linking of aliases, but correlation may still be possible through mail headers, timing, account metadata, identical OpenPGP preferences, or server-side information. Generated certificates should therefore minimize unnecessary shared metadata.

Result

This design provides:

• one independent PGP identity per reverse alias,
• no externally visible cryptographic relationship between aliases,
• deterministic recovery without storing large numbers of private keys,
• local/on-demand private-key generation by Proton clients,
• straightforward integration with SimpleLogin through per-alias public keys.