PaperlayerView exact revision on arXiv

Source-linked AI summary

They Will See Johnny's Message: A Measurement Study of Post-Quantum Cryptography Across Email Delivery Paths

Jaehwan Park, Sunghyun Park, Kevin Nam, Doowon Kim

arXiv:2610.36145v1cs.CR

TL;DR

HNDL threatens the confidentiality of long-lived email, and prior evidence does not jointly establish PQC readiness across service roles, peer negotiation, and message encryption. This study combines Internet-scale service measurements with controlled tests, finding widespread gaps between available capability and usable protection.

  • Problem

    Email traffic can be recorded for future decryption, while prior research does not jointly examine PQC across email services, peer negotiation, and usable message encryption.

    Source: §1 · p. 1

  • Method

    The study combines three snapshots of Top 1M-associated submission, relay, access, and webmail services with controlled tests of clients, sending MTAs, and OpenPGP and S/MIME implementations.

    Source: §1 · p. 2

  • Results

    Fewer than half of domains at every service stage support PQC, and only two of eight tested sending providers negotiate it despite five accepting it inbound.

    Source: §1 · p. 2, §8 · p. 8

  • Takeaways & Limitations

    PQC capability must translate into negotiated connections and working encryption, and handshake failures should not fall back to plaintext.

    Source: §8 · pp. 8–9

    Population-level measurements cover discovered endpoints, and controlled observations do not estimate PQC use across email traffic or provider-internal hops.

    Source: §3 · p. 4

Abstract

from arXiv · show

Harvest-now, decrypt-later (HNDL) attacks make the transition to post-quantum cryptography (PQC) urgent for email. This paper presents a systematic measurement that jointly examines PQC deployment across email service stages, negotiation by communicating peers, and usable message encryption. Endpoint-level support alone does not establish PQC readiness across email workflows because submission, relay, and access use independently negotiated Transport Layer Security (TLS) connections. We therefore combine three snapshots of relay, submission, access, and webmail services associated with the Tranco Top~1M domains with controlled tests of mail clients, sending servers, and OpenPGP and S/MIME implementations. Our measurements reveal a transition concentrated among a few providers, with available capability not consistently translating into actual use. Fewer than half of the domains in each service panel support PQC, and Google alone accounts for approximately 87\% of hybrid-capable relay domains. Only two of eight tested sending providers negotiate PQC with our receiver, although five accept it inbound. When TLS groups are restricted to PQC, four of the six incompatible senders fall back to plaintext where unencrypted SMTP remains permitted. At the message layer, limited native key generation, key-format incompatibilities, and backend integration failures further constrain usable PQC encryption.

1 Introduction

HNDL threatens long-lived email confidentiality, while independently negotiated connections and rare message encryption make readiness a workflow-wide question. This study measures PQC availability, negotiation, and message encryption, finding concentrated deployment and persistent gaps between capability and use.

Motivation

  • HNDL attacks can expose recorded email traffic to future decryption, making PQC urgent for correspondence that may remain sensitive for years.Email crosses the public Internet, and protecting it requires more than securing one TLS connection because submission, relay, and access are independently negotiated.Source: §1 · p. 1

Research gap and questions

  • Prior work does not jointly measure PQC availability across email services, peer negotiation, and usable message-level protection.The study organizes these gaps into questions about server-side TLS, client-side TLS, and OpenPGP and S/MIME encryption.Source: §1 · p. 1

Main findings

  • Fewer than half of domains in each service panel support PQC, and only two of eight tested sending providers negotiate it despite five accepting it inbound.Under PQC-only TLS restrictions, four of six incompatible senders deliver in plaintext where unencrypted SMTP remains permitted; none of the 27 tested configurations generates a PQC key natively.Source: §1 · p. 2

Approach and contributions

  • The study combines three snapshots of Top 1M-associated email services with controlled tests of clients, sending servers, and message-encryption implementations.Its contributions include a structured corpus of 19 OpenPGP keys and six S/MIME certificates, and analysis of operational barriers including software defects.Source: §1 · p. 2

2 Background and Related Work

Email delivery involves service roles and independently protected connections, while message encryption can protect content across the transport path. The paper distinguishes PQC capability from negotiated use and situates its measurements alongside prior work that leaves these dimensions uncombined.

2.1 Email Delivery Path

  • Email delivery has submission, relay, retrieval, and webmail roles; these services can use different providers and security policies, and each TLS connection has an initiating client and accepting server.A domain may use multiple MX hosts, including backups, or a filtering service before the mailbox provider.Source: §2.1 · pp. 2–3

2.2 Confidentiality at Two Layers

  • TLS protects individual adjacent connections, whereas OpenPGP and S/MIME protect message content independently of the transport path.Usable message protection requires a working sequence of key generation or import, encryption, and decryption; opportunistic SMTP may retry without TLS after negotiation fails.Source: §2.2 · p. 3

2.3 Post-Quantum Key Exchange in TLS

  • In TLS 1.3, advertising a PQC group differs from supplying its initial share or negotiating it; evaluated PQC groups require TLS 1.3 and may be hybrid or pure ML-KEM.The study focuses on key establishment and content confidentiality, not post-quantum authentication.Source: §2.3 · p. 3

2.4 Related Work

  • Prior work covers web-facing PQC TLS, classical email security, or message-encryption usability, but does not jointly assess email-role deployment, initiating peers, and message encryption.Table 1 compares representative prior-work scope; this study also evaluates PQC key generation, import, and successful message exchange.Source: §2.4 · p. 3, Table 1 · p. 3

3 Study Overview

The study combines population-level scans of email-service endpoints with controlled experiments that examine whether capability translates into negotiated or usable protection. Its conclusions are bounded by endpoint discovery and the tested configurations.

Study design

  • Three snapshots scan submission, relay, access, and webmail endpoints associated with the Tranco Top 1M domains to measure population-level capability.Controlled experiments test mail clients, outbound MTAs, MTA software, and OpenPGP and S/MIME implementations for case-level observations about negotiated and usable protection.Source: §3 · pp. 3–4

Scope and limitations

  • Population-level rates cover only discovered endpoints, while controlled experiments do not estimate PQC use across email traffic.Their observations apply to the tested applications, platforms, providers, and configurations.Source: §3 · p. 4
  • The external vantage point does not observe provider-internal hops, and the study excludes post-quantum certificates because HNDL threatens confidentiality rather than retroactive signature forgery.Public probes stop after the handshake, and controlled delivery experiments use only accounts and receiving servers under the researchers' control.Source: §3 · p. 4

4 RQ1: Server-Side PQC Deployment

Across the measured service panels, more than half of domains lack PQC support, while capability is concentrated among a few providers and can vary across a domain’s mail hops. The measurements assess stable service panels and show why relay readiness depends on every listed MX host.

4.1 Measurement Method

  • The study uses three snapshots to form fixed panels of domains with successful TLS, and counts a stage as PQC-capable if at least one discovered endpoint accepts an evaluated PQC group.Each service stage has its own denominator; the reported rates measure available capability rather than uniform support across alternative endpoints.Source: §4.1 · p. 4

4.2 PQC Adoption per Stage

  • More than half of domains at every stage lack PQC support; 86–94% of mail-hop domains and 78% of webmail domains already use TLS 1.3, while TLS 1.2 cannot negotiate PQC.The authors suggest that missing PQC is mostly due to servers not enabling a hybrid group, rather than TLS version.Source: §4.2 · p. 4
  • A domain’s hybrid support does not alone secure mail: protection requires both sending and receiving domains to adopt PQC, and hybrid support determines the protected population because pure ML-KEM support is a subset.MX hosts agree in 99.0% of cases, with exceptions examined in the primary-and-backup comparison.Source: §4.2 · p. 4

4.3 PQC Adoption per Provider

  • Google accounts for approximately 87% of hybrid-capable relay domains and 96% to 97% of PQC-capable submission and access domains, and is the only named provider with observed pure ML-KEM support.The provider breakdown groups stable domains by provider.Source: §4.3 · p. 4, Table 2 · p. 5
  • Microsoft serves approximately 103,000 to 114,000 panel domains per stage without observed PQC support, while most measured filtering gateways also lack it; Cloudflare Email Security supports hybrid exchange.A traditional-only gateway prevents PQC on the external relay connection even when the mailbox provider supports it.Source: §4.3 · p. 5
  • PQC support varies by hop: Namecheap and Yahoo support hybrid exchange on measured relay domains but not submission or access, while Fastmail shows the reverse; webmail hybrid support rose from 36.2% to 41.0% in two weeks.On relay, submission, and access, hybrid support rose by at most 0.4 percentage points over four weeks, while pure ML-KEM support was unchanged.Source: §4.3 · p. 5

4.4 Primary and Backup MX Consistency

  • For 417 domains a hybrid-capable primary MX has a classical-only backup, while 1,222 have the reverse pattern, so checking every listed MX host is necessary to assess relay readiness.MTA-STS and DANE do not require a PQC key-exchange group, so a backup can meet the applicable authentication policy while remaining classical-only.Source: §4.4 · p. 5

5 RQ2: PQC Negotiation by Clients and MTAs

Tests of mail clients, provider MTAs, and SMTP software examine whether PQC is offered and negotiated across client-facing and relay connections. PQC-capable servers do not ensure PQC use: negotiation varies by platform and provider, and incompatible senders may fall back to plaintext under PQC-only restrictions.

5.1 Mail Client Negotiations in Practice

  • PQC negotiation depends on client platform: Gmail on web, Android, and iOS and Apple Mail on iOS and iPadOS negotiate X25519MLKEM768, while Apple Mail on macOS and Outlook on Windows use TLS 1.2.Outlook on macOS offers a PQC group but does not negotiate one because its connection passes through a Microsoft relay without PQC support.Source: §5.1 · p. 5, Table 3 · p. 6
  • Client tests use PQC-capable Gmail submission and access servers to attribute traditional handshakes to clients; relay tests send from eight providers to a controlled MX under all-groups and PQC-only configurations.The controlled MX records offered groups, key shares, selected groups, and retries.Source: §5.1 · p. 5, §5.2 · pp. 5–6

5.2 MX Relay Negotiations in Practice

  • Only Migadu and Namecheap offer and negotiate PQC outbound among eight tested providers, although five accept it inbound; under PQC-only restrictions, four of six senders without PQC deliver in plaintext.Google and Proton defer delivery after retries during the one-day observation period, whereas Mailgun, Yahoo, Outlook, and Zoho deliver without STARTTLS.Source: §5.2 · p. 6, Table 4 · p. 6

5.3 SMTP Software

  • In tests of Exim and Postfix, Postfix advertises X25519MLKEM768 but supplies only an X25519 key share, while non-PQC builds of both senders fall back to plaintext toward a PQC-only receiver.Exim 4.100.1 also had a PQC-only receiver configuration bug that developers fixed after it was reported; Exim and Postfix account for 94% of surveyed mail servers.Source: §5.3 · pp. 6–7

6 RQ3: Message-Level PQC Support

Message-level PQC usability remains limited: no tested configuration generates PQC keys natively, and backend and format differences prevent many imported keys from completing encryption and decryption.

6.2 Native Key Generation

  • None of the 27 tested configurations supports native PQC key generation, leaving users to generate keys externally and import them manually.The tested key-generation interfaces offer only RSA and ECC algorithms.Source: §6.2 · p. 7, §6.1 · p. 7

6.3 Key Import

  • The backend, key version, and primary key’s signature algorithm largely determine OpenPGP import results, rather than the client itself.Ten of 24 OpenPGP configurations reject all 19 keys; the remaining GnuPG- and PGPony-based configurations import different sets.Source: §6.3 · p. 7
  • All 11 GnuPG-based configurations reject keys with ML-DSA or SLH-DSA primary keys because GnuPG cannot verify their signatures binding the ML-KEM subkey.Matched keys with Ed25519 primary keys are accepted.Source: §6.3 · p. 7
  • Three PGPony-based configurations import A3 and A4 but fail to exchange messages, while importing prohibited key N3 also fails to enable encryption.PGPony-based configurations import N3 despite RFC 9980 prohibiting it.Source: §6.3 · p. 7
  • Four S/MIME certificate stores accept all six ML-KEM certificates, but only Windows CNG and OpenSSL complete an exchange.NSS, .NET PKCS, and Horde’s OpenSSL import certificates but cannot use them.Source: §6.3 · p. 7

6.4 Encryption and Decryption

  • Only eight of eleven GnuPG-based configurations exchange messages with every imported key except three v4 keys, while PGPony-based configurations exchange messages only with A1, N2, and R-v6.For the three v4 keys, GnuPG 2.5.24 adds twelve zero octets to the PKESK fingerprint; removing them restores decryption.Source: §6.4 · pp. 7–8
  • OpenPGP exchange failures arise from integration defects as well as key incompatibilities, including errors handling warnings, v4 key IDs, and differing fingerprint lengths.Horde fails on every imported key, Postbox on v5 and v6 keys, and Mailpile on G1–G3.Source: §6.4 · p. 8
  • Only Outlook Classic and Mutt complete S/MIME exchanges with all six certificates; other tested configurations cannot encrypt to them.The successful configurations use stores that parse ML-KEM certificates and support KEMRecipientInfo.Source: §6.4 · p. 8

7 Discussion

The discussion recommends converting PQC capability into negotiated, per-hop protection and usable message encryption, while noting that the measurements do not establish traffic-wide prevalence or explain adoption decisions.

7.1 Deployment Recommendations

  • Receivers should reject unencrypted SMTP before restricting key-exchange groups, and senders should defer or bounce on handshake failure rather than retry without TLS.A PQC-only receiver caused four of six non-PQC senders and both MTAs built without ML-KEM to deliver in plaintext.Source: §7.1 · p. 8
  • Providers should enable PQC on outbound MTAs and verify that ClientHello carries the key share, because accepting hybrid groups inbound does not ensure outbound negotiation.Three providers accept hybrid groups inbound but offer none outbound; default Postfix advertises X25519MLKEM768 without its key share.Source: §7.1 · p. 8
  • PQC should be enabled per service and direction, with operators checking every listed MX host and gateways treating their own support as a precondition.A traditional-only filtering gateway, non-PQC backup MX, or unconfigured relay can remove PQC from a path whose endpoints support it.Source: §7.1 · p. 8
  • Clients should consider native PQC key generation, validate imports against RFC 9980, and use consistent backend logic for import and encryption.Until then, the paper recommends v6 keys with a traditional primary and ML-KEM subkey for users whose correspondents may use either tested backend.Source: §7.1 · p. 8

7.2 Limitations and Responsible Disclosure

  • Server measurements describe discovered infrastructure rather than traffic or complete message paths, and controlled experiments are case studies of tested applications, providers, and configurations.A single vantage point over four weeks limits geographic and temporal generalization; the eight-provider sample does not estimate traffic-wide negotiation or plaintext fallback.Source: §7.2 · p. 8
  • The experiments identify technical barriers but do not explain organizational adoption decisions; operator interviews or vendor surveys are left for future work.The authors reported the Exim configuration bug and notified several software maintainers of integration failures.Source: §7.2 · p. 8

8 Conclusion

The paper measures PQC readiness across email services and controlled client, server, and message-encryption tests. It finds that support often does not become negotiated or usable protection, with plaintext fallback and message-layer implementation barriers among the observed gaps.

8 Conclusion

  • The study combines Internet-scale server probes with controlled tests of clients, sending MTAs, and message encryption.It measures PQC readiness across email services.Source: §8 · p. 8
  • Fewer than half of domains in every service panel support PQC, and only two of eight tested sending providers negotiate PQC despite five accepting it inbound.Google accounts for approximately 87% of hybrid-capable relay domains.Source: §8 · p. 8
  • Post-quantum capability is not post-quantum communication: negotiation, working message encryption, and avoiding plaintext fallback remain necessary.The conclusion notes that four of six incompatible senders deliver in plaintext under PQC-only restrictions where unencrypted SMTP remains permitted.Source: §8 · pp. 8–9

A Email Protocols and TLS Modes

The appendix materials describe email service protocols and endpoint discovery, the key-exchange groups probed, provider-level PQC support, and SMTP software behavior under default and PQC-only configurations.

A Email Protocols and TLS Modes

B Email Infrastructure Discovery

  • For relay, submission, and access, respectively, 540,650 of 666,181, 366,955 of 385,135, and 374,680 of 388,161 domains complete a TLS handshake.Webmail discovery yields 69,150 domains completing a TLS handshake after page verification.Source: B Email Infrastructure Discovery · p. 10

C Key Exchange Groups in OpenSSL v3.5.

D PQC Support by Provider and Service

  • Figure 2 compares hybrid PQC support across providers and service stages; its numbers give domain counts, colors show providers’ hybrid-capable fractions, and dashed markings indicate pure ML-KEM.The figure identifies five gateways: Nable, Barracuda, TrendMicro, Hornetsecurity, and Cisco.Source: D PQC Support by Provider and Service · p. 10, Figure 2 · p. 11

E PQC Behavior of SMTP Software

  • Table 9 summarizes Exim and Postfix receiver and sender behavior under default and PQC-only TLS configurations, including delivery by a sender without ML-KEM support.Its legend distinguishes hybrid negotiation, an advertised hybrid group without its initial share, and no support; footnotes mark plaintext or failure outcomes under restrictions.Source: E PQC Behavior of SMTP Software · pp. 10–11, Table 9 · p. 11

F.1 Provider and MX Observations

PQC-capable email services are unevenly distributed across providers, and observed growth is concentrated among a few providers. Webmail support often depends on hosting infrastructure, while several large providers show no support in the measured snapshots.

Provider and MX Observations

  • Strato accounts for 97% and 83% of net submission and access increases, respectively, while Migadu accounts for 54% of the net relay increase.These changes were observed across snapshots from August 17 to September 14.Source: §F.1 · p. 11
  • 143,539 submission domains and 150,132 access domains are PQC-capable in the current analysis.Source: §F.1 · p. 11
  • Among 52,596 self-hosted webmail domains, 3,261 gained hybrid support and 72 lost it between August 31 and September 14.Most pages use cPanel or Roundcube, with TLS terminated by the hosting server; this suggests independent hosting servers enabled hybrid key exchange.Source: §F.1 · p. 11
  • Microsoft, Zoho, and Yandex showed no PQC support in any of the three snapshots, which cover four weeks and do not establish a long-term adoption trend.Source: §F.1 · p. 11
  • Google commonly operates a capable primary MX while backups may lack support, and in the reverse category Google may instead be a capable backup.Examples include leboncoin.fr and hotstar.com, whose Google primaries support hybrid exchange while their backups do not.Source: §F.1 · p. 11

F.2 Message-Level Test Details

The message-level tests use a corpus designed to isolate key-format and algorithm factors, alongside 27 client–platform configurations for importing keys and exchanging encrypted messages.

F.2 Message-Level Test Details

  • The corpus uses a minimal conformant baseline key and varies key version, primary algorithm, KEM subkey, and certificate packaging to test message-level PQC support.Except for G1–G3, each key differs from at least one other corpus key in exactly one factor.Source: §F.2.1 · p. 11
  • A1–A7 are RFC 9980 test vectors; N, R, and L keys extend the combinations, while N3 and N4 are prohibited negative controls.G1–G3 are GnuPG-generated keys for testing interoperability with its LibrePGP-based backend; S/MIME certificates cover three ML-KEM levels in standard and legacy PKCS#12 packaging.Source: §F.2.1 · pp. 11–12
  • The tests cover 27 client–platform configurations, and the matrix distinguishes successful end-to-end exchange, import-only success, import failure, and corrected GnuPG PKESK encoding.The table also marks tracks that do not apply to a client.Source: §F.2.1 · p. 12, Table 11 · p. 12

F.2.2 Detailed Per-Client Support Matrix.

The support matrix exposes failures at key validation, packet encoding, client integration, and S/MIME envelope construction, so successful import does not always yield message exchange.

F.2.2 Detailed Per-Client Support Matrix

  • All GnuPG configurations reject prohibited N3 and N4, but PGPony imports N3 without conformance validation and later rejects encryption because it accepts only v6 keys.No message is sent under the nonconforming key; the failure is due to its v5 version, not the prohibited combination.Source: §F.2.2 · p. 12
  • GnuPG 2.5.24's v4 PKESK encoding appends twelve zero octets, causing recipient parsing to read a zero algorithm identifier; removing them restores decryption.Source: §F.2.2 · p. 12
  • Postbox derives key IDs using a rule valid only for v4, while Mailpile loses G1–G3 records because their primary and subkey fingerprints have different lengths.G1–G3 succeed in Postbox because their v4 primary satisfies the key-ID rule and their v5 subkey avoids the PKESK flaw.Source: §F.2.2 · p. 12
  • Horde fails every exchange because it treats a warning from GnuPG's obsolete option as an error, while PGPony's ML-DSA keys fail after import because encryption and decryption use bc-java.Horde's failure is unrelated to PQC.Source: §F.2.2 · p. 12
  • S/MIME support depends on recipient-key and envelope APIs: NSS accepts only RSA and EC recipients, and eM Client and Horde use paths lacking KEMRecipientInfo.Mutt uses OpenSSL's CMS API, unlike Horde's legacy PKCS#7 API.Source: §F.2.2 · p. 12
Loading 2610.36145v1…