NTRU KEM Security Considerations
draft-kosuge-cfrg-ntru-kem-security-considerations-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Haruhisa Kosuge , Akira Nagai , Xagawa Keita | ||
| Last updated | 2026-06-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kosuge-cfrg-ntru-kem-security-considerations-00
Crypto Forum H. Kosuge
Internet-Draft A. Nagai
Intended status: Informational NTT
Expires: 21 December 2026 K. Xagawa
TII
19 June 2026
NTRU KEM Security Considerations
draft-kosuge-cfrg-ntru-kem-security-considerations-00
Abstract
This document records security considerations for the NTRU key
encapsulation mechanism that is being standardized in ISO/IEC 29192-4
Amendment 2. It is intended to help protocol designers and
implementers decide when NTRU is safe to use, and how to use it
without creating avoidable security regressions.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 December 2026.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Kosuge, et al. Expires 21 December 2026 [Page 1]
Internet-Draft NTRU KEM Security June 2026
Table of Contents
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Is It Safe To Use? . . . . . . . . . . . . . . . . . . . . . 2
2.1. Security Goal . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Basis for Confidence . . . . . . . . . . . . . . . . . . 3
2.3. Assumptions and Conditions . . . . . . . . . . . . . . . 4
3. How To Safely Use It . . . . . . . . . . . . . . . . . . . . 4
3.1. Encodings and Sizes . . . . . . . . . . . . . . . . . . . 4
3.2. Validation and Failure Handling . . . . . . . . . . . . . 5
3.3. Randomness Requirements . . . . . . . . . . . . . . . . . 5
3.4. Side-Channel Considerations . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Normative References . . . . . . . . . . . . . . . . . . . . 6
6. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Scope
For this document, the authoritative specification for NTRU is the
current IETF draft for NTRU key encapsulation ([NTRU-DRAFT]). This
document uses that IETF draft as the normative reference. The draft
also defines the parameter sets and includes test vectors.
The parameter sets in scope for this document are listed below.
* ntruhps2048677: 930-byte public key and ciphertext, 1234-byte
serialized private key, 32-byte shared secret.
* ntruhps4096821: 1230-byte public key and ciphertext, 1590-byte
serialized private key, 32-byte shared secret.
* ntruhps40961229: 1842-byte public key and ciphertext, 2366-byte
serialized private key, 32-byte shared secret.
* ntruhrss701: 1138-byte public key and ciphertext, 1450-byte
serialized private key, 32-byte shared secret.
* ntruhrss1373: 2401-byte public key and ciphertext, 2983-byte
serialized private key, 32-byte shared secret.
The serialized private-key sizes report the size of a reference
serialization of the private-key values. They are included only for
implementation reference; this document does not define a private-key
interchange format, and KEM interoperability does not depend on one.
2. Is It Safe To Use?
Kosuge, et al. Expires 21 December 2026 [Page 2]
Internet-Draft NTRU KEM Security June 2026
2.1. Security Goal
For the parameter sets listed above, the NTRU draft identifies IND-
CCA2 as the desired security property and lists the intended bit
strength for each parameter set ([NTRU-DRAFT]). This document treats
IND-CCA2 security as the relevant baseline for protocol use because
the calling protocol may need security against active attacks,
ciphertext manipulation, or authentication-sensitive composition
([RFC9180], [AUTHKEM]).
Representative IETF examples are HPKE, where RFC 9180 requires that
the KEM used within HPKE support the protocol's desired security
properties and analyzes the KEM in IND-CCA2 terms ([RFC9180]), and
KEMTLS / AuthKEM, where the IETF draft for KEM-based authentication
in TLS 1.3 discusses handshake security and authentication goals that
go beyond an IND-CPA-only KEM assumption ([AUTHKEM]).
The parameter sets above target the usual NIST-style strength levels
([NTRU-DRAFT]): ntruhps2048677 and ntruhrss701 target 128-bit
security, ntruhps4096821 targets 192-bit security, and
ntruhps40961229 and ntruhrss1373 target 256-bit security.
2.2. Basis for Confidence
Confidence in NTRU comes from two statements:
* The underlying public-key encryption primitive is believed secure
against the known attacks for the published parameter sets, based
on the public NTRU cryptanalysis and parameter-selection rationale
([NTRU-NIST], [NISTIR8309]).
* The SXY transform gives a provable IND-CCA2 KEM construction in
the quantum random oracle model under the assumptions stated by
Saito, Xagawa, and Yamakawa ([SXY]).
The first statement is a primitive-security estimate. For lattice-
based schemes, the standard assessment is to analyze the best known
lattice attacks, commonly expressed with a core-SVP style cost model.
This model reduces the attack cost to a BKZ block size and to the
cost of the sieving step used inside lattice reduction ([CORE-SVP],
[NTRU-NIST], [NISTIR8309]). These estimates are not proofs; they
rely on the current understanding that no more efficient public
attack is known for the selected parameters. Using this framework
and the parameter-set security table in the NTRU draft, the published
NTRU parameter sets are assessed as meeting their intended bit-
security targets ([NTRU-DRAFT], [NTRU-NIST]).
Kosuge, et al. Expires 21 December 2026 [Page 3]
Internet-Draft NTRU KEM Security June 2026
2.3. Assumptions and Conditions
The assumptions behind the NTRU security claim form a reduction
chain. As discussed above, there is a reduction from the KEM
security claim to the security of the underlying deterministic
public-key encryption primitive, and the primitive security is then
assessed through the hardness of the associated NTRU lattice search
problems.
The first kind of assumption is that the proof model matches the
implementation:
* The values sampled by KeyGen and Encaps have the required entropy
and distribution.
* The implementation exposes only the public inputs and outputs
modeled by the security game. In particular, no secret-dependent
information is available through side-channel behavior, fault
behavior, logs, or other externally visible behavior.
Under those black-box conditions, the remaining computational
assumption is that the associated NTRU lattice search problems are
hard at the claimed security level. The primitive-security estimate
for this assumption is discussed in Section 2.2.
3. How To Safely Use It
3.1. Encodings and Sizes
Implementations need to use the canonical encodings defined by the
NTRU specification ([NTRU-DRAFT]):
public_key = pack_Rq0(H)
ciphertext = pack_Rq0(C)
shared secret = SHA3-256(pack_S3(R_shared,3) || pack_S3(M_shared,3))
All public keys and ciphertexts are fixed-length byte strings. The
exact sizes for the parameter sets covered by this document are
listed in Section 1. Implementations need to reject public-key or
ciphertext inputs whose lengths do not match the selected parameter
set.
The NTRU draft describes the private key as internal values. A
private-key interchange format is not required for KEM
interoperability and is not defined in this document.
Kosuge, et al. Expires 21 December 2026 [Page 4]
Internet-Draft NTRU KEM Security June 2026
Protocol profiles that carry public keys or ciphertexts should use
the canonical NTRU byte strings for those values. In particular, the
packed Rq0 byte string is the protocol representation of a public key
or ciphertext, and the 32-byte SHA3-256 output is the KEM shared
secret.
3.2. Validation and Failure Handling
The NTRU draft defines validation primarily through decoding of
packed polynomials and through decapsulation-time validity checks
([NTRU-DRAFT]). This document does not add a separate public-key
validity check.
Implementations need to check that public-key and ciphertext byte
strings have the exact length for the selected parameter set before
applying unpack_Rq0. After unpacking, the reconstructed polynomial
is the value processed by the NTRU algorithm.
During decapsulation, implementations need to perform the parameter-
set-specific validity checks on the reconstructed randomizer and
message/preimage values, and then select either K1 or the fallback
value K2 exactly as specified by NTRU. If those checks fail, NTRU
decapsulation outputs K2 rather than a detailed cryptographic error.
The decapsulation interface should not reveal whether K1 or K2 was
selected; in particular, implementations should not return distinct
error codes or expose ciphertext validity through logs, metrics, or
debugging interfaces.
3.3. Randomness Requirements
NTRU uses randomness in two different places ([NTRU-DRAFT]):
* KeyGen samples the secret polynomials, abstractly the short secret
and auxiliary values produced by the parameter-set-specific
sample_fg procedure. Any private fallback material s used to
compute K2 is also private key material.
* Encaps samples the ephemeral pair R_shared,3 and M_shared,3 using
the parameter-set-specific sample_rm procedure.
For both uses, sampled values need to have the entropy and
distributions required by the selected parameter set. They can be
obtained directly from a true random source, or from a
cryptographically secure pseudorandom generator or deterministic
random bit generator that is properly seeded with entropy at least
equal to the security level of the selected parameter set ([RFC4086],
[RFC8937]). If a pseudorandom generator is used, its seed and
internal state need to be protected as secret state.
Kosuge, et al. Expires 21 December 2026 [Page 5]
Internet-Draft NTRU KEM Security June 2026
Encapsulation randomness needs to be freshly and independently
sampled for every encapsulation.
3.4. Side-Channel Considerations
Implementations need to avoid leaking secret-dependent information
through timing, branches, memory access patterns, or other externally
visible behavior. This applies to secret-dependent processing in
KeyGen, Encaps, and Decaps, including handling of decapsulation
validity checks and selection between K1 and K2.
Decapsulation should not expose whether the normal value K1 or the
fallback value K2 was selected. Public length checks and parsing
decisions that depend only on public byte string lengths need not be
constant-time.
Sensitive intermediate values should be cleared as soon as they are
no longer needed. Implementations deployed in environments with
physical or shared-resource attack exposure should apply the usual
side-channel protections for modern KEM implementations.
4. IANA Considerations
This document has no IANA actions.
5. Normative References
[NTRU-DRAFT]
Fluhrer, S., Prorock, M., Celi, S., Gray, J., Xagawa, K.,
and H. Kosuge, "NTRU Key Encapsulation", Work in Progress,
Internet-Draft, draft-fluhrer-cfrg-ntru,
<https://datatracker.ietf.org/doc/html/draft-fluhrer-cfrg-
ntru>.
6. Informative References
[AUTHKEM] Wiggers, T., Celi, S., Schwabe, P., Stebila, D., and N.
Sullivan, "KEM-based Authentication for TLS 1.3", Work in
Progress, Internet-Draft, draft-celi-wiggers-tls-authkem,
<https://datatracker.ietf.org/doc/draft-celi-wiggers-tls-
authkem/>.
[CORE-SVP] Bernstein, D., "Visualizing Size-Security Tradeoffs for
Lattice-Based Encryption",
<https://csrc.nist.gov/CSRC/media/Events/Second-PQC-
Standardization-Conference/documents/accepted-papers/
bernstein-visualizing-paper.pdf>.
Kosuge, et al. Expires 21 December 2026 [Page 6]
Internet-Draft NTRU KEM Security June 2026
[NISTIR8309]
NIST, "Status Report on the Second Round of the NIST Post-
Quantum Cryptography Standardization Process", NIST
IR 8309, <https://doi.org/10.6028/NIST.IR.8309>.
[NTRU-NIST]
NTRU Team, "NTRU Round 3 Submission Package to the NIST
Post-Quantum Cryptography Project",
<https://csrc.nist.gov/CSRC/media/Projects/post-quantum-
cryptography/documents/round-3/submissions/NTRU-
Round3.zip>.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", RFC 4086,
<https://www.rfc-editor.org/rfc/rfc4086.html>.
[RFC8937] Thomson, M., "Randomness Improvements for Security
Protocols", RFC 8937,
<https://www.rfc-editor.org/rfc/rfc8937.html>.
[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180,
<https://www.rfc-editor.org/rfc/rfc9180.html>.
[SXY] Saito, T., Xagawa, K., and T. Yamakawa, "Tightly-Secure
Key-Encapsulation Mechanism in the Quantum Random Oracle
Model", <https://eprint.iacr.org/2017/1005.pdf>.
Authors' Addresses
Haruhisa Kosuge
NTT
Email: hrhs.kosuge@ntt.com
Akira Nagai
NTT
Email: akira.nagai@ntt.com
Keita Xagawa
TII
Email: xagawa@gmail.com
Kosuge, et al. Expires 21 December 2026 [Page 7]