Security Considerations for NTRU-family KEMs
draft-liu-cfrg-ntru-family-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 | Yijian Liu , Xianhui Lu | ||
| Last updated | 2026-06-21 | ||
| 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-liu-cfrg-ntru-family-security-considerations-00
Crypto Forum Research Group Y. Liu
Internet-Draft X. Lu
Intended status: Informational IIE, CAS
Expires: 24 December 2026 22 June 2026
Security Considerations for NTRU-family KEMs
draft-liu-cfrg-ntru-family-security-considerations-00
Abstract
This document provides an informational review checklist for NTRU-
family KEMs. It covers security claims, assumptions, reductions,
concrete attack estimates, correctness and decryption-failure
analyses, and implementation behavior for named specifications and
parameter sets. It does not define a KEM interface or make
recommendations among candidate KEMs.
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 24 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.
Liu & Lu Expires 24 December 2026 [Page 1]
Internet-Draft NTRU-family KEM Considerations June 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Review Checklist Conventions . . . . . . . . . . . . . . . . 3
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Classification of NTRU-family KEMs . . . . . . . . . . . 5
3.3. Parameter Scope . . . . . . . . . . . . . . . . . . . . . 6
4. Proof . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Security Notion and Reduction . . . . . . . . . . . . . . 7
4.2. Transform . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Assumption Inventory . . . . . . . . . . . . . . . . . . 8
5.2. NTRU Assumption Details . . . . . . . . . . . . . . . . . 9
5.3. RLWE-like Assumption Details . . . . . . . . . . . . . . 9
6. Concrete Attacks . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Estimation Tools and Cost Models . . . . . . . . . . . . 10
6.2. Lattice-Reduction Attacks . . . . . . . . . . . . . . . . 11
6.3. Combinatorial and Hybrid Attacks . . . . . . . . . . . . 11
6.4. Structural Attacks . . . . . . . . . . . . . . . . . . . 11
7. Parameters and Implementation . . . . . . . . . . . . . . . . 13
7.1. Distribution and Sampling . . . . . . . . . . . . . . . . 13
7.2. Implementation . . . . . . . . . . . . . . . . . . . . . 14
8. Decryption Failure . . . . . . . . . . . . . . . . . . . . . 15
8.1. Correctness Statement . . . . . . . . . . . . . . . . . . 15
8.2. Average-Case and Worst-Case Bounds . . . . . . . . . . . 16
8.3. Failure-Based Attacks . . . . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
12. Informative References . . . . . . . . . . . . . . . . . . . 17
Appendix A. Scheme-Specific Notes . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
The first post-quantum KEM deployment wave is centered on ML-KEM
[FIPS203], but NTRU-family KEMs continue to be discussed because some
have long public review records and some offer compact public keys or
ciphertexts in particular parameter regimes. These properties
motivate clear review criteria, but they do not by themselves imply a
recommendation for use.
Liu & Lu Expires 24 December 2026 [Page 2]
Internet-Draft NTRU-family KEM Considerations June 2026
This draft records family-level review questions for NTRU-family KEM
specifications and security analyses. It follows the style of
security-considerations work, such as draft-sfluhrer-cfrg-ml-kem-
security-considerations-05, an active individual Internet-Draft last
updated 2026-05-13 and active as of 2026-06-10, for ML-KEM
[I-D.sfluhrer-cfrg-ml-kem-security-considerations].
The schemes discussed in this document are reviewed as layered
constructions. The NTRU-derived public key, usually represented by a
short quotient such as h, is the object of private key recovery or
public key indistinguishability analysis. The plaintext-hiding part
can be viewed, for review purposes, as an RLWE- or RLWR-style
encryption layer, or as a related ring-based encryption layer, in
which the public ring element is the NTRU-derived h rather than an
independently sampled public element. This is an analytical
viewpoint: NTRU predates LWE and RLWE. Transform choices, decoding
mechanisms, and decryption-failure behavior remain scheme-specific
and security-relevant.
2. Review Checklist Conventions
This document uses lowercase checklist language. Phrases such as "is
expected to", "should", and "reviewers should check whether" are
review guidance only. They are not BCP 14 keywords, do not create
standards-track requirements, and do not define a standalone KEM
interface.
3. Scope
The scope covers KEMs whose security analysis relies on an NTRU-type
relation. This includes schemes whose public key is of the form,
informally, a short quotient in a polynomial ring, and schemes whose
private-key recovery problem is naturally expressed as finding a
short vector in an NTRU lattice.
A similar layered analysis may apply to constructions in which
private-key recovery is NTRU-like, while plaintext or ciphertext
indistinguishability is analyzed using RLWE, RLWR, or a related ring
or module assumption.
The scope is family-level review criteria for KEM specifications and
security analyses. The terms below are used throughout those
criteria.
3.1. Terminology
NTRU-family KEM: A KEM whose security analysis relies on an NTRU-
Liu & Lu Expires 24 December 2026 [Page 3]
Internet-Draft NTRU-family KEM Considerations June 2026
type relation. The term is descriptive and does not imply that
all such schemes share a single hardness assumption or a single
proof strategy.
Public-key-security layer: The layer that hides or protects the
private NTRU trapdoor from the public key. In many NTRU-family
KEMs this is analyzed as an NTRU search or decision problem.
Message-security layer: The layer that hides the encapsulated
secret, seed, message, or intermediate value under the public key.
Depending on the scheme, this layer may be analyzed using RLWE,
RLWR, subset-sum parity RLWE, or another assumption.
Correctness error: The probability that decapsulation of a valid
ciphertext generated by encapsulation under a valid public key
outputs a shared secret different from the encapsulated shared
secret.
DFR: Decryption failure rate. This document uses DFR synonymously
with correctness error for valid KEM encapsulations unless
explicitly stated otherwise. Failure on malformed ciphertexts is
a validation and oracle-resistance issue, not the same quantity.
Perfect correctness: The property that valid encapsulations always
decapsulate to the same shared secret under the specified
algorithms and parameter sets.
Message-conditional DFR(m): For a fixed accepted message or encoded
plaintext m, Message-conditional DFR(m) = Pr[(pk, sk) <- KeyGen;
ct <- Encrypt(pk, m): Decrypt(sk, ct) != m]. The probability is
over key generation and encryption randomness of the underlying
PKE. Although the KEM interface does not expose such a message
parameter, KEMs built from a PKE by an FO-like, OAEP-like, SXY-
like, or related transform inherit correctness requirements from
that underlying encryption layer. Any proof loss or failure term
associated with decryption failure should therefore state the
corresponding PKE correctness quantity. This document also writes
this quantity as DFR(m).
Average-case DFR: E_m[Message-conditional DFR(m)], equivalently
E_m[DFR(m)], for the stated distribution on the accepted message
or encoded-plaintext space.
Worst-case DFR: max_m Message-conditional DFR(m), equivalently max_m
DFR(m), over the stated accepted message or encoded-plaintext
space. In some NTRU-family analyses, the maximum is expected to
be attained by a distinguished message pattern, such as an all-one
message with no zero coefficients.
Liu & Lu Expires 24 December 2026 [Page 4]
Internet-Draft NTRU-family KEM Considerations June 2026
3.2. Classification of NTRU-family KEMs
Review should classify a scheme according to the design dimensions in
this section. The classification makes comparison possible without
expressing a recommendation or maturity determination.
The classification has two independent parts. The first is
technical: which message-security layer is analyzed, which transform
is used, and whether the KEM has perfect correctness or nonzero DFR.
The second is evidentiary: what public review, standardization,
implementation, and deployment evidence exists. The evidentiary part
should distinguish public-review history, participation in a
competition or standardization process, deployment evidence, national
or regional selection, and recent research status. These categories
are not interchangeable.
For example, the NTRU-HPS/HRSS parameter sets from the NTRU NIST PQC
Round 3 submission [NTRU-R3] have multi-year public review records
through the NIST PQC process [NISTIR8413]. The individual CFRG
document draft-fluhrer-cfrg-ntru-03 is expired and no longer active
as of 2026-06-10; it is based on that submission, but includes
additional parameter sets. For example, the draft reports the
addition of ntruhps40961229 and ntruhrss1373 [I-D.fluhrer-cfrg-ntru].
Claims should state whether they apply only to the NIST-reviewed
parameter sets or also to later additions, and what evidence supports
each case. NTRU-HPS/HRSS standardization work is also reported in
ISO/IEC JTC 1/SC 27 lightweight-cryptography work; review needs to
identify the exact ISO/IEC text and status rather than relying on the
family label [NTRU-ISO-WORK] [ISO29192-4-AMD2].
Other schemes have different evidence profiles. Streamlined NTRU
Prime is one variant in the NTRU Prime submission, alongside NTRU
LPRime. NTRU Prime was a third-round alternate PKE/KEM candidate in
the NIST PQC process, but NIST did not select it for standardization
or move it to the fourth round [NISTIR8413] [NTRU-PRIME]. NTRU+
[NTRU-PLUS] was selected as a final PKE/KEM algorithm in the Korean
Post-Quantum Cryptography Competition [KPQC-RESULTS]. Recent
proposals such as BAT [BAT], NEV [NEV], DAWN [DAWN], and CTRU/CNTR
[CTRU-CNTR] are included to identify scheme-specific review issues.
Compactness or performance claims from those proposals are not
treated as deployment guidance in this document.
Scheme-specific notes for these entries appear in Appendix A. The
checklist items in the following sections are review prompts for
discussion.
Liu & Lu Expires 24 December 2026 [Page 5]
Internet-Draft NTRU-family KEM Considerations June 2026
3.3. Parameter Scope
A security claim applies only to a named specification, version,
parameter set, and option set. For lattice KEMs, the relevant
parameters usually include the polynomial degree or module dimension,
modulus, secret distribution, noise distribution, compression or
rounding parameters, and decoding radius. Changing one of these can
change both correctness and attack cost. The parameter review should
not treat these values as independent table entries. Lattice
parameters interact: changing the modulus, distribution sparsity, or
compression can improve size or performance while changing the best
attack and the correctness margin.
* For each in-scope parameter set, the document is expected to state
the intended classical and quantum security strength, the
estimation model, and the margin relative to the target.
* Reviewers should check whether parameters are evaluated as a
tuple. It is not sufficient to state that the ring dimension is
large or that the modulus is conventional. The analysis should
consider dimension, modulus, secret/noise distributions, entropy,
decoding radius, ciphertext compression, and rejection rules
together. If a parameter set is proposed primarily for
compactness, the document should explain which margin is being
spent.
4. Proof
Proof review separates what is proved from what is assumed or
estimated. A CCA-secure KEM claim usually rests on one or more
underlying hardness assumptions, such as NTRU and RLWE. A scheme may
also use a related assumption justified by a reduction or modeling
step, for example a reduction that derives RLWR hardness from RLWE
hardness under stated conditions. Separately, the scheme proof
reduces the KEM security notion to those assumptions and other losses
of the concrete scheme.
Liu & Lu Expires 24 December 2026 [Page 6]
Internet-Draft NTRU-family KEM Considerations June 2026
[ CCA KEM claim ]
|
| scheme-level reductions
v
[ CPA PKE or related encryption ]
|
| scheme-to-assumption reductions
v
[ Variant assumptions: RLWR, ssp RLWE ]
|
| assumption-level reductions
v
[ Base assumptions: NTRU, RLWE ]
Concrete estimates apply to bottom-level problem instances.
These reduction layers serve different purposes. An assumption-level
reduction relates mathematical problems, such as RLWR and RLWE under
stated conditions. A scheme-level reduction relates a construction
to its assumptions, for example by applying a Fujisaki-Okamoto-style
transform to a CPA encryption scheme. Once both layers are stated,
concrete estimates should be reported for the instantiated bottom-
level problem instances.
4.1. Security Notion and Reduction
The scheme-level claim should say what security notion is claimed and
how the construction reaches that notion from its underlying
encryption mechanism.
* The proof discussion should keep four claims separate: underlying
hardness assumptions, hardness reductions for those assumptions,
the KEM proof reduction, and concrete attack estimates. A result
in one layer is not a substitute for another.
* The claimed KEM security notion and proof model should be stated,
such as ROM, QROM, standard model, or a mixed model.
4.2. Transform
Transforms are security-relevant because they determine the reduction
target, oracle behavior, and security property. The construction may
use a Fujisaki-Okamoto-style transform, an FO-like transform, an
OAEP-like transform, a SXY-like transform, or an Average-Case to
Worst-Case (ACWC)-like transform. FO-like, OAEP-like, and SXY-like
transforms are used, under their stated models and conditions, to
obtain CCA-style security from an underlying CPA-secure encryption
primitive. An ACWC-family layer can convert an average-case DFR
Liu & Lu Expires 24 December 2026 [Page 7]
Internet-Draft NTRU-family KEM Considerations June 2026
analysis into a worst-case DFR bound for the encoded message space
[ACWC-NTRU]. If an error-correcting or auxiliary-code layer is part
of the design, the proof should explain how that layer is bound to
the KEM transform rather than treating it as an implementation
detail.
* The construction path from the underlying encryption mechanism to
the KEM should be identified. Examples include Fujisaki-Okamoto-
style transforms, FO-like, OAEP-like, SXY-like transforms, or
other transforms.
* If the construction uses an ACWC-family layer with GOTP/SOTP-style
encoding, the document should state the concrete algorithms and
explain how the layer is bound to the scheme-level reduction.
NTRU+ is an example that uses ACWC2 with SOTP encoding
[NTRU-PLUS].
5. Assumptions
Assumptions are the mathematical problems on which the KEM relies,
not proof reductions or concrete attack estimates for one parameter
set. In NTRU-family designs this distinction matters because the
public key or trapdoor part may be NTRU-like while the message-
security layer is analyzed using RLWE, RLWR, ssp RLWE, or another
related assumption.
Each assumption should be precise enough for a reader to see what
problem is claimed to be hard, whether a hardness reduction is being
invoked, and whether attacks on one layer interact with attacks on
another.
5.1. Assumption Inventory
The problem inventory should identify exactly which NTRU, RLWE, RLWR,
or related instances are relied on for the stated security claim to
hold.
* Every hardness assumption used by the KEM should be identified.
For NTRU-family KEMs this often includes an NTRU assumption for
the public-key-security layer and an RLWE-, RLWR-, or related
assumption for the message-security layer. The statement should
include the exact problem variant, ring or module, modulus,
distributions, sample form, parameter tuple, and search or
decision form.
* The analysis should distinguish search assumptions from decision
assumptions, average-case assumptions from worst-case reductions,
and algebraic assumptions from generic lattice assumptions. If a
Liu & Lu Expires 24 December 2026 [Page 8]
Internet-Draft NTRU-family KEM Considerations June 2026
hardness reduction is invoked, the document should state the
theorem, direction, parameter restrictions, distribution
restrictions, approximation factor, and loss.
* If a scheme relies on both NTRU and RLWE, RLWR, or a related
layer, the document should state whether the instances are
independent or algebraically coupled. The analysis should account
for attacks that use both layers or reuse the same parameter
tuple.
5.2. NTRU Assumption Details
The NTRU layer controls public key or trapdoor security. Its review
needs the exact algebraic setting and the actual secret distribution,
because both lattice attacks and combinatorial attacks depend on
them.
* The NTRU ring or algebraic structure, modulus, secret
distribution, public key distribution, invertibility conditions,
and key-generation rejection rules should be specified.
5.3. RLWE-like Assumption Details
The message-security layer may be modeled as RLWE, RLWR, or a related
variant using the NTRU-derived public element. The document should
state whether this is a standard assumption, a reduced variant, or a
scheme-specific modeling step.
* If the message-security layer is analyzed using RLWE, RLWR, or a
related assumption, the document should specify the sample form,
ring or module, modulus, secret distribution, error or rounding
distribution, number of samples, and any structural restriction
imposed by the NTRU public key.
* If the layer uses ssp RLWE or another nonstandard variant, the
document should define that assumption and explain how it differs
from ordinary RLWE.
6. Concrete Attacks
Concrete security estimates answer a different question from
reductions: for the instantiated parameter tuple, what is the cost of
the best known attacks on the underlying problems? The answer
depends on the attack families considered, estimator version,
treatment of sparse or low-entropy distributions, and the BKZ/SVP
cost model. Because these models continue to evolve, a security
document should report explicit margin rather than merely meeting the
target under one estimator run.
Liu & Lu Expires 24 December 2026 [Page 9]
Internet-Draft NTRU-family KEM Considerations June 2026
An NTRU-family security document should present concrete estimates as
reproducible review evidence, not as final theorems. The estimate
should make clear which attack is being run, which lattice is being
attacked, which model turns a BKZ block size into a bit cost, and
which structural or algebraic attacks are outside the tool's default
model.
Dual and hybrid-dual estimates require particular care in security
estimates. Small-modulus encryption layers can make hybrid-dual
attacks appear competitive in estimator output while estimating
message-layer security, but recent analyses have identified heuristic
assumptions in dual-sieve and dual-sieve-FFT style estimates, and
provable dual analyses can give different or more conservative costs
[DUAL-SIEVE-WORK] [PROVABLE-DUAL-LWE]. A report that relies on a
dual or hybrid-dual estimate should therefore state whether the
estimates it used are heuristic or provable.
Distribution parameters enter different attack families in different
ways. Lattice-reduction attacks are primarily sensitive to the
realized scale of the secret, error, or auxiliary distribution, such
as its standard deviation or target norm relative to the modulus and
lattice dimension. Combinatorial attacks are primarily sensitive to
the size and entropy of the sampled support. Hybrid attacks combine
partial guessing with lattice reduction, so the analysis needs both
views: the entropy cost of the guessed part and the changed lattice
instance after that guess.
6.1. Estimation Tools and Cost Models
Estimator output is useful only when it is reproducible and scoped to
the problem being estimated. The report should make clear whether
the run is estimating an NTRU public key instance, an LWE/RLWE/RLWR-
style message-security instance, or a side-information instance.
* Concrete lattice-security estimates should be reproducible with a
public estimator or public scripts. For NTRU-family KEMs,
commonly relevant tools include the lattice-estimator
[LATTICE-ESTIMATOR] [LATTICE-ESTIMATOR-DOCS] for LWE, NTRU, and
SIS estimates, and the leaky-LWE-Estimator [LEAKY-LWE-ESTIMATOR]
[DDGR20] when the analysis models leakage or side information.
The lattice-estimator documentation includes NTRU parameter
classes and attacks relevant to NTRU public-key instances,
including overstretched parameter regimes. Therefore, a generic
LWE estimate alone is not a sufficient check for an NTRU public-
key claim [LATTICE-ESTIMATOR-DOCS]. The report should state the
tool, version or commit, script or command line, parameter
encoding, non-default options, attack list, and any local patches.
Liu & Lu Expires 24 December 2026 [Page 10]
Internet-Draft NTRU-family KEM Considerations June 2026
* A document should not present estimator output without specifying
the cost model. It should state the lattice-reduction cost model,
such as ADPS16/Core-SVP [ADPS16] or MATZOV-style [MATZOV22], and
the quantum cost model, such as Grover search or a quantum random
walk.
6.2. Lattice-Reduction Attacks
Lattice-reduction estimates are sensitive to dimension, modulus,
target norm, and the cost model used to convert a block size into
work. Those inputs should be visible rather than hidden inside an
estimator printout.
* The estimate should state the lattice basis being attacked, the
target vector, the target norm, the lattice dimension, the
modulus, and the BKZ/SVP cost model.
6.3. Combinatorial and Hybrid Attacks
Sparse or structured distributions also create search problems. A
hybrid attack combines this search with lattice reduction, so both
the entropy of the guessed part and the resulting lattice instance
matter.
* For sparse or low-entropy secrets, the analysis should include
combinatorial and hybrid attacks with exact size of support set.
6.4. Structural Attacks
Ring and modulus choices can create algebraic structure that affects
attacks, not only implementation speed. The review should state
which ring is used or relied on.
Recent work on module-lattice reduction gives a more specific ring
issue. For power-of-two cyclotomic rings of the form x^n + 1 with n
= 2^k, the cited module-BKZ analysis does not predict a smaller block
size than the corresponding unstructured BKZ estimate. For other
cyclotomic rings, the number field discriminant can give module-BKZ a
sublinear blocksize gain, which corresponds to a subexponential
speedup. This matters for NTRU-family schemes that use non-power-of-
two cyclotomic rings, such as the tri-cyclotomic rings used by NTRU+
and by CTRU/CNTR [MODULE-BKZ].
Tri-cyclotomic rings of the form Z[x]/(x^n - x^(n/2) + 1), with n =
2^i 3^j, need an additional coefficient-embedding check. In the
power-of-two cyclotomic case, multiplication by x is a signed
rotation of the coefficient vector. In a tri-cyclotomic ring, the
reduction rule x^n = x^(n/2) - 1 means that multiplication by x is
Liu & Lu Expires 24 December 2026 [Page 11]
Internet-Draft NTRU-family KEM Considerations June 2026
not a signed permutation in the usual coefficient basis. As a
result, multiplication matrices may have rows with different
Euclidean norms, and monomial multiples of the same secret may have
different coefficient-embedding norms. Analyses of NTRU+ and CTRU/
CNTR have discussed this ring shape in the context of polynomial
multiplication and decryption-error behavior [NTRU-PLUS] [CTRU-CNTR].
The same issue is also relevant to concrete security estimates: the
shortest target vector in the coefficient-embedding NTRU lattice may
be a monomial multiple such as x^k * (g, f) or, for message-security
estimates, x^k * (e, -s), rather than the unshifted vector. The
expected variation may be small for a proposed parameter set, but the
norm distribution over monomial multiples should still be measured or
bounded and fed into the target norm used by lattice-reduction,
combinatorial, and hybrid estimates.
* The review should discuss whether the ring, modulus, automorphism
group, CRT decomposition, or subfield structure creates a known
structural acceleration. Examples include weak rings, weak
moduli, automorphism-based reductions, and attacks that use the
ring structure to lower hybrid-attack complexity or otherwise
change concrete structured-LWE estimates when applicable
[RING-HYBRID-2026] [MLWE-LWE-GAP].
* The ring choice should be identified as power-of-two cyclotomic or
another cyclotomic ring, and the analysis should account for known
module-BKZ behavior for that ring when estimating lattice-
reduction costs [MODULE-BKZ].
* If a message-security layer is modeled as Module-LWE, Ring-LWE,
Module-LWR, Ring-LWR, or a sparse-secret variant over a structured
polynomial ring, the document should evaluate attacks that use the
algebraic structure in the attack algorithm, not only in the
problem definition. Recent algebra-aware analyses include
enhanced hybrid decoding attacks against Module/Ring-LWE that use
the ring structure to accelerate guessing and decoding steps, and
concrete comparisons between MLWE and unstructured LWE estimates
[RING-HYBRID-2026] [MLWE-LWE-GAP]. The analysis should state
whether such techniques apply to the RLWE/RLWR-style layer used by
the NTRU-family PKE or KEM construction, and how the conclusion
changes under sparse or low-entropy secret and error
distributions.
* If the scheme uses a tri-cyclotomic ring of the form Z[x]/(x^n -
x^(n/2) + 1) or a ring of the form Z[x]/(x^n - x - 1) in which
multiplication by x^i does not preserve the Euclidean norm,
reviewers should check whether the security analysis accounts for
the norms of all relevant monomial multiples of the target secret
vectors, not only the displayed (g, f) or (e, -s) representative.
Liu & Lu Expires 24 December 2026 [Page 12]
Internet-Draft NTRU-family KEM Considerations June 2026
7. Parameters and Implementation
Implementation review depends on the parameter tuple, randomness,
sampler behavior, side-channel assumptions, test vectors, and
interoperability behavior being specified together. Omitting one of
these can invalidate proof assumptions or concrete security
estimates.
Review should identify the authoritative specification and parameter
sets, explain option choices, state how distributions are sampled in
real implementations, and identify the artifacts needed for
reproducible testing.
7.1. Distribution and Sampling
Sampling defines the distribution actually attacked. Security
estimates should use the realized discrete distribution, including
support, variance, entropy, rejection behavior, and side-channel
properties, not only the name of the distribution.
* Every distribution used for secrets, errors, messages, coins,
masks, or auxiliary values should be specified exactly. If a
value is expanded from a seed, the expansion function, domain
separation, byte order, rejection rule, and failure behavior
should be specified.
* If a discrete Gaussian is used, the document is expected to
specify the parameterization convention, support, truncation rule
if any, exact or approximate sampling algorithm, and realized
variance. Security estimates should use the realized discrete
distribution, not only the nominal continuous variance.
BAT gives a concrete example. If the centered discrete Gaussian has
mass proportional to exp(-x^2/(2*sigma^2)) over all integers x, then
its realized variance is sum_x x^2 rho_sigma(x) / sum_x rho_sigma(x).
For the BAT value sigma = 0.596, this gives a realized standard
deviation of about 0.588. The important point is that concrete
estimates should use the realized distribution, including variance,
tails, support, entropy, and sampler behavior.
* Implementers should not silently replace a specified distribution
with a lower-variance or lower-entropy approximation. A faster
sampler should be adopted carefully, since it may change variance,
tails, support size, or entropy, which changes the security
analysis.
Liu & Lu Expires 24 December 2026 [Page 13]
Internet-Draft NTRU-family KEM Considerations June 2026
* Secret-dependent sampler behavior needs to be addressed.
Distribution samplers and rejection loops should not leak secrets
through timing, memory access, iteration count, or other
observable behavior unless a deployment-specific side-channel
argument justifies the design.
7.2. Implementation
Implementation considerations focus on preserving the proof
assumptions and avoiding new oracles. Constant-time behavior,
complete decapsulation checks, and zeroization are part of the
security boundary, not optional engineering notes.
Constant-time claims should be supported by both code review and tool
evidence. Dynamic tools such as TIMECOP can be useful for this
review: TIMECOP uses Valgrind's memcheck mechanism with annotated
secret data to look for timing leaks caused by secret-dependent
branches or memory accesses [TIMECOP-TOOLS] [TIMECOP]. Such tools
are not a complete proof. They depend on the chosen annotations and
test inputs, and TIMECOP's own documentation notes limitations such
as variable-time CPU instructions and language/toolchain coverage.
In NTRU-family KEMs, secret-dependent sampling, branching, or
comparison can reveal whether a ciphertext was valid, whether
decoding crossed a boundary, or which branch of the transform was
taken. The document needs to identify those operations and give
measures such as constant-time comparison, no externally
distinguishable failure signal, constant-time fallback-key selection,
and negative tests that exercise malformed inputs.
When an FO or FO-like KEM includes a re-encryption check, that check
is security-critical even when honestly generated ciphertexts
decapsulate correctly without exposing a missing check in basic
functional tests. Work on verifiable decapsulation reports that an
HQC reference implementation flaw in this area went unnoticed for
months and shows how confirmation codes can make faulty re-encryption
visible in ordinary correctness tests [VERIFIABLE-DECAPS]. Such
techniques may be considered by new designs or profiles, when the
transform description and security proof account for them.
* Key generation, encapsulation, and decapsulation implementations
are expected to avoid secret-dependent branches and secret-
dependent variable-time arithmetic unless a deployment-specific
side-channel analysis justifies them. Polynomial multiplication,
base conversion, modular reduction, sampling, decoding, and
comparison should be covered by that analysis.
Liu & Lu Expires 24 December 2026 [Page 14]
Internet-Draft NTRU-family KEM Considerations June 2026
* A document should report constant-time testing with TIMECOP,
ctgrind, dudect, or a comparable tool, including tool version,
compiler, optimization flags, platform, tested operations, and
warnings.
* If a design uses confirmation codes or another mechanism intended
to make skipped verification visible in tests, the document should
describe how the mechanism is bound into the KEM transform and
security proof.
* Secret keys and intermediate secrets should be zeroized when no
longer needed. The document should identify long-lived secrets,
ephemeral secrets, seeds, and decoded messages that require
zeroization.
8. Decryption Failure
Decryption failure is a central distinction inside the NTRU family.
Some KEMs claim perfect correctness for the specified parameter sets.
Others intentionally accept a nonzero decryption-failure probability
and try to make that probability small enough, and model it
explicitly.
The review should separate mathematical correctness of valid
encapsulations from behavior on malformed ciphertexts. A correctness
bound says whether valid encapsulations decapsulate to the same
shared secret. Invalid-input behavior is an oracle-resistance and
side-channel question. Failure-based attacks connect the two when an
adversary can make many decapsulation queries.
DFR analysis here uses message-conditional DFR as the base quantity.
In many Ring-LWE or Module-LWE (R/M-LWE) encryption layers, the
decryption-error event is dominated by noise and rounding terms and
may be independent of the encoded message. In NTRU-style encryption
layers, the decryption error usually depends on the message. The
analysis therefore should state whether DFR(m) is message-
independent, averaged over a specified message distribution, or
bounded by a maximum over the specified message space.
8.1. Correctness Statement
Correctness is the claim that a valid encapsulation decapsulates to
the same shared secret. That claim is separate from invalid-input
behavior, but it depends on the exact algorithms, encodings,
accepted-key conditions, and transform checks.
Liu & Lu Expires 24 December 2026 [Page 15]
Internet-Draft NTRU-family KEM Considerations June 2026
* The correctness claim should state whether the KEM has perfect
correctness or a nonzero DFR. For perfect-correctness claims, it
should give the algebraic reason no valid encapsulation can fail.
* For nonzero-DFR claims, the document is expected to state the DFR
target, whether the bound is average-case or worst-case.
Following mainstream schemes, the nonzero DFR should be smaller
than, or approximately equal to, 2^-128 except in specific
application scenarios with justification.
8.2. Average-Case and Worst-Case Bounds
Average-case and worst-case DFR are derived from the message-
conditional function DFR(m). The distinction matters when some
messages have higher failure probability than others.
The size of the gap is scheme-specific. In some NTRU-family DFR
analyses, the message-dependent term is not the dominant contribution
to decryption failure, so average-case and worst-case DFR may be
close; NEV and DAWN are examples where the analysis should make that
relationship explicit [NEV] [DAWN]. In other designs, such as NTRU+
and BAT, ACWC-family coding is used to control the gap by converting
an average-case DFR analysis into a worst-case bound for the encoded
message space [NTRU-PLUS] [BAT] [ACWC-NTRU].
* A worst-case DFR relates to the reduction loss from CPA to CCA, so
a scheme should not claim CCA security only from a negligible
average-case DFR when the worst-case DFR is relatively large.
* If a DFR estimate assumes independence of ring coefficients,
decoding events, or error groups, the document should justify the
assumption or provide a conservative fallback bound.
8.3. Failure-Based Attacks
Failure-based attacks are not only single-target attacks. If the
coins or encryption randomness used in encapsulation are derived only
from the encoded message, and not from the recipient public key or a
collision-resistant identifier for it, then the same offline search
for failure-prone messages may be reusable across many public keys.
This is a multi-target concern: the attacker is not merely trying
many ciphertexts against one key, but trying to amortize the search
across a population of keys. NTRU+ records this issue in its change
history and binds F(pk) into the encapsulation hashing for multi-
target security [NTRU-PLUS].
Liu & Lu Expires 24 December 2026 [Page 16]
Internet-Draft NTRU-family KEM Considerations June 2026
High decryption-failure probabilities have led to concrete attacks or
attack analyses, including attacks against ss-ntru-pke [DFR-SS-NTRU]
and LAC [DFR-LAC]. Failure boosting and multi-target analyses
further show that the relevant review question is not only the
average-case DFR, but also the cost of finding the first useful
failing ciphertext under the attacker's query and target model
[MULTITARGET-DFR]. Many lattice KEM designs have used 2^-128 as a
DFR target, but this is a review convention rather than a theorem
that implies CCA security. Reviewers should consider it together
with the maximum number of decapsulation queries and the number of
distinct decapsulation keys exposed to those queries.
* Multi-target failure-based attacks should be analyzed. If
encapsulation randomness is derived from the message but not from
the public key, a public-key hash, or another collision-resistant
public-key identifier, the document should explain why offline
searches for failure-prone messages cannot be reused across
targets. If such reuse cannot be ruled out, the derivation should
bind the public key or identifier into the randomness derivation
and the security proof.
* Reviewers should check that decapsulation does not expose a
distinguishable failure signal through the external interface
except where the KEM specification proves that the signal is safe.
The usual safe behavior is to return a pseudorandom fallback
shared secret using constant-time control flow.
9. Security Considerations
This document is itself a security-considerations document. It does
not specify a protocol, define a new KEM, or approve any KEM for use.
Security guidance appears throughout the preceding sections,
including the discussion of assumptions, concrete attacks,
implementation behavior, and decryption-failure analysis. A scheme-
specific document that uses these criteria is still expected to
provide its own security considerations for the exact specification,
parameter sets, and protocol contexts in scope.
10. IANA Considerations
This document has no IANA actions.
11. Acknowledgments
TODO acknowledge.
12. Informative References
Liu & Lu Expires 24 December 2026 [Page 17]
Internet-Draft NTRU-family KEM Considerations June 2026
[ACWC-NTRU]
Duman, J., Hoevelmanns, K., Kiltz, E., Lyubashevsky, V.,
Seiler, G., and D. Unruh, "A Thorough Treatment of Highly-
Efficient NTRU Instantiations", Public-Key Cryptography --
PKC 2023 65-94, DOI 10.1007/978-3-031-31368-4_3, 2023,
<https://doi.org/10.1007/978-3-031-31368-4_3>.
[ADPS16] Alkim, E., Ducas, L., Poppelmann, T., and P. Schwabe,
"Post-Quantum Key Exchange--A New Hope", USENIX
Security 25, 2016,
<https://www.usenix.org/conference/usenixsecurity16/
technical-sessions/presentation/alkim>.
[BAT] Fouque, P., Kirchner, P., Pornin, T., and Y. Yu, "BAT:
Small and Fast KEM over NTRU Lattices", IACR Trans.
Cryptogr. Hardw. Embed. Syst. 2022(2), 240-265,
DOI 10.46586/tches.v2022.i2.240-265, 2022,
<https://doi.org/10.46586/tches.v2022.i2.240-265>.
[CTRU-CNTR]
Liang, Z., Fang, B., Zheng, J., and Y. Zhao, "Compact and
Efficient KEMs over NTRU Lattices", Computer Standards &
Interfaces 89, 103828, DOI 10.1016/j.csi.2023.103828,
2024, <https://doi.org/10.1016/j.csi.2023.103828>.
[DAWN] Liu, Y., Zhang, Y., Lu, X., Cheng, Y., and Y. Yin, "DAWN:
Smaller and Faster NTRU Encryption via Double Encoding",
Advances in Cryptology -- ASIACRYPT 2025 LNCS 16247,
396-427, DOI 10.1007/978-981-95-5099-9_13, 2025,
<https://doi.org/10.1007/978-981-95-5099-9_13>.
[DDGR20] Dachman-Soled, D., Ducas, L., Gong, H., and M. Rossi, "LWE
with Side Information: Attacks and Concrete Security
Estimation", Advances in Cryptology -- CRYPTO 2020 LNCS
12171, 329-358, DOI 10.1007/978-3-030-56880-1_12, 2020,
<https://doi.org/10.1007/978-3-030-56880-1_12>.
[DFR-LAC] Guo, Q., Johansson, T., and J. Yang, "A Novel CCA Attack
Using Decryption Errors Against LAC", Advances in
Cryptology -- ASIACRYPT 2019 LNCS 11921, 82-111,
DOI 10.1007/978-3-030-34578-5_4, 2019,
<https://doi.org/10.1007/978-3-030-34578-5_4>.
Liu & Lu Expires 24 December 2026 [Page 18]
Internet-Draft NTRU-family KEM Considerations June 2026
[DFR-SS-NTRU]
D'Anvers, J., Guo, Q., Johansson, T., Nilsson, A.,
Vercauteren, F., and I. Verbauwhede, "Decryption Failure
Attacks on IND-CCA Secure Lattice-Based Schemes", Public-
Key Cryptography -- PKC 2019 LNCS 11443, 565-598,
DOI 10.1007/978-3-030-17259-6_19, 2019,
<https://doi.org/10.1007/978-3-030-17259-6_19>.
[DUAL-SIEVE-WORK]
Ducas, L. and L. N. Pulles, "Does the Dual-Sieve Attack on
Learning with Errors Even Work?", Advances in Cryptology
-- CRYPTO 2023 LNCS 14083, 37-69,
DOI 10.1007/978-3-031-38548-3_2, 2023,
<https://doi.org/10.1007/978-3-031-38548-3_2>.
[FIPS203] NIST, "Module-Lattice-Based Key-Encapsulation Mechanism
Standard", FIPS 203, 2024,
<https://doi.org/10.6028/NIST.FIPS.203>.
[FO-PREFIX-HASHING]
Duman, J., Hoevelmanns, K., Kiltz, E., Lyubashevsky, V.,
and G. Seiler, "Faster Lattice-Based KEMs via a Generic
Fujisaki-Okamoto Transform Using Prefix Hashing",
Proceedings of the 2021 ACM SIGSAC Conference on Computer
and Communications Security 2722-2737,
DOI 10.1145/3460120.3484819, 2021,
<https://doi.org/10.1145/3460120.3484819>.
[I-D.fluhrer-cfrg-ntru]
Fluhrer, S., Prorock, M., Celi, S., Gray, J., Keita, X.,
and H. Kosuge, "NTRU Key Encapsulation", Work in Progress,
Internet-Draft, draft-fluhrer-cfrg-ntru-03, 7 July 2025,
<https://datatracker.ietf.org/doc/html/draft-fluhrer-cfrg-
ntru-03>.
[I-D.sfluhrer-cfrg-ml-kem-security-considerations]
Fluhrer, S., Dang, Q., Mattsson, J. P., Milner, K., and D.
Shiu, "ML-KEM Security Considerations", Work in Progress,
Internet-Draft, draft-sfluhrer-cfrg-ml-kem-security-
considerations-05, 13 May 2026,
<https://datatracker.ietf.org/doc/html/draft-sfluhrer-
cfrg-ml-kem-security-considerations-05>.
Liu & Lu Expires 24 December 2026 [Page 19]
Internet-Draft NTRU-family KEM Considerations June 2026
[ISO29192-4-AMD2]
ISO/IEC, "ISO/IEC 29192-4:2013/DAmd 2 Information
technology -- Security techniques -- Lightweight
cryptography -- Part 4: Mechanisms using asymmetric
techniques -- Amendment 2", Last-Modified 2026-06-10,
Accessed 2026-06-10, 10 June 2026,
<https://www.iso.org/standard/90706.html>.
[KPQC-RESULTS]
KpqC, "Korean Post-Quantum Cryptography Competition: Final
Algorithms", Accessed 2026-06-10, n.d.,
<https://kpqc.or.kr/competition_02.html>.
[LATTICE-ESTIMATOR]
Albrecht, M. R., "Security Estimates for Lattice
Problems", Git commit 27a581b, Accessed 2026-06-10, 6 June
2026, <https://github.com/malb/lattice-estimator/
commit/27a581b>.
[LATTICE-ESTIMATOR-DOCS]
Albrecht, M. R., "Lattice Estimator Documentation",
Documentation latest, Last-Modified 2025-09-04,
Accessed 2026-06-10, 4 September 2025,
<https://lattice-estimator.readthedocs.io/en/latest/>.
[LEAKY-LWE-ESTIMATOR]
Ducas, L., "A Sage Toolkit to Attack and Estimate the
Hardness of LWE with Side Information", Git
commit 0a9caf8, Accessed 2026-06-10, 14 November 2022,
<https://github.com/lducas/leaky-LWE-Estimator/
commit/0a9caf8>.
[MATZOV22] MATZOV, "Report on the Security of LWE: Improved Dual
Lattice Attack", 2022,
<https://doi.org/10.5281/zenodo.6493704>.
[MLWE-LWE-GAP]
Ogilvie, T., "On the Concrete Hardness Gap Between MLWE
and LWE", IACR ePrint 2026/279, 2026,
<https://eprint.iacr.org/2026/279>.
[MODULE-BKZ]
Ducas, L., Engelberts, L., and P. de Perthuis, "Predicting
Module-Lattice Reduction", Advances in Cryptology --
ASIACRYPT 2025 LNCS 16247, 133-166,
DOI 10.1007/978-981-95-5099-9_5, 2026,
<https://doi.org/10.1007/978-981-95-5099-9_5>.
Liu & Lu Expires 24 December 2026 [Page 20]
Internet-Draft NTRU-family KEM Considerations June 2026
[MULTITARGET-DFR]
D'Anvers, J. and S. Batsleer, "Multitarget Decryption
Failure Attacks and Their Application to Saber and Kyber",
LNCS 13177, 3-33, DOI 10.1007/978-3-030-97121-2_1, 2022,
<https://doi.org/10.1007/978-3-030-97121-2_1>.
[NEV] Zhang, J., Feng, D., and D. Yan, "NEV: Faster and Smaller
NTRU Encryption Using Vector Decoding", Advances in
Cryptology -- ASIACRYPT 2023 LNCS 14444, 157-189,
DOI 10.1007/978-981-99-8739-9_6, 2023,
<https://doi.org/10.1007/978-981-99-8739-9_6>.
[NISTIR8413]
NIST, "Status Report on the Third Round of the NIST Post-
Quantum Cryptography Standardization Process", NIST
IR 8413-upd1, 2022,
<https://doi.org/10.6028/NIST.IR.8413-upd1>.
[NTRU-ISO-WORK]
"NTRU: Post-Quantum Cryptography", Accessed 2026-06-10,
n.d., <https://info.isl.ntt.co.jp/crypt/ntru/>.
[NTRU-PLUS]
Park, J. H. and J. Kim, "NTRU+: Compact Construction of
NTRU Using Simple Encoding Method", KpqC Final Version,
Last-Modified 2026-02-05, Accessed 2026-06-10, 30 January
2026, <https://data.ntruplus.org/NTRU+.pdf>.
[NTRU-PRIME]
"NTRU Prime", Last-Modified 2022-03-03,
Accessed 2026-06-10, 3 March 2022,
<https://ntruprime.cr.yp.to>.
[NTRU-R3] Chen, C., Danba, O., Hoffstein, J., Huelsing, A.,
Rijneveld, J., Schanck, J. M., Saito, T., Schwabe, P.,
Whyte, W., Xagawa, K., Yamakawa, T., and Z. Zhang, "NTRU
Algorithm Specifications and Supporting Documentation",
NIST PQC Round 3 Submission NTRU, 30 September 2020,
<https://csrc.nist.gov/CSRC/media/Projects/post-quantum-
cryptography/documents/round-3/submissions/NTRU-
Round3.zip>.
[PROVABLE-DUAL-LWE]
Pouly, A. and Y. Shen, "Provable Dual Attacks on Learning
with Errors", Advances in Cryptology -- EUROCRYPT
2024 LNCS 14657, 256-285,
DOI 10.1007/978-3-031-58754-2_10, 2024,
<https://doi.org/10.1007/978-3-031-58754-2_10>.
Liu & Lu Expires 24 December 2026 [Page 21]
Internet-Draft NTRU-family KEM Considerations June 2026
[RFC9941] Friedl, M., Mojzis, J., and S. Josefsson, "Secure Shell
(SSH) Key Exchange Method Using Hybrid Streamlined NTRU
Prime sntrup761 and X25519 with SHA-512:
sntrup761x25519-sha512", RFC 9941, DOI 10.17487/RFC9941,
April 2026, <https://www.rfc-editor.org/rfc/rfc9941>.
[RING-HYBRID-2026]
Hou, J. and H. Jiang, "Careful with the Ring: Enhanced
Hybrid Decoding Attacks against Module/Ring-LWE", IACR
ePrint 2026/366, 2026, <https://eprint.iacr.org/2026/366>.
[TIMECOP] Post-Apocalyptic Crypto, "TIMECOP", Last-
Modified 2020-08-08, Accessed 2026-06-10, 8 August 2020,
<https://www.post-apocalyptic-crypto.org/timecop/>.
[TIMECOP-TOOLS]
CRoCS, "Constant Time Analysis with Timecop", Last-
Modified 2026-02-04, Accessed 2026-06-10, 4 February 2026,
<https://crocs-muni.github.io/ct-tools/tutorials/timecop>.
[VERIFIABLE-DECAPS]
Glabush, L., Guenther, F., Hoevelmanns, K., and D.
Stebila, "Verifiable Decapsulation: Recognizing Faulty
Implementations of Post-quantum KEMs", Advances in
Cryptology -- CRYPTO 2025 LNCS 16002, 543-574,
DOI 10.1007/978-3-032-01881-6_17, 2025,
<https://doi.org/10.1007/978-3-032-01881-6_17>.
Appendix A. Scheme-Specific Notes
This appendix gives scheme-specific background for the classification
of NTRU-family KEMs.
Liu & Lu Expires 24 December 2026 [Page 22]
Internet-Draft NTRU-family KEM Considerations June 2026
+=============+=====================+===============================+
| Scheme | Evidence category | Watchpoints |
+=============+=====================+===============================+
| NTRU-HPS | NIST PQC; ISO/IEC | Parameter consistency |
| | work | |
+-------------+---------------------+-------------------------------+
| NTRU-HRSS | NIST PQC; ISO/IEC | Entropy loss from non- |
| | work | negative-correlation |
| | | sampling |
+-------------+---------------------+-------------------------------+
| Streamlined | NIST PQC alternate; | Concrete security of |
| NTRU Prime | sntrup761 | NTRU and RLWR on Galois |
| | deployment | group |
+-------------+---------------------+-------------------------------+
| NTRU+ | KpqC final | Concrete security of |
| | selection | NTRU on tri-cyclotomic |
| | | ring |
+-------------+---------------------+-------------------------------+
| BAT | Research | Discrete Gaussian |
| | publication | realization |
+-------------+---------------------+-------------------------------+
| NEV | Research | Concrete security of ssp |
| | publication | RLWE |
+-------------+---------------------+-------------------------------+
| DAWN | Research | Convolution-independence |
| | publication | assumptions |
+-------------+---------------------+-------------------------------+
| CTRU/CNTR | Research | Concrete security of |
| | publication | NTRU on tri-cyclotomic |
| | | ring |
+-------------+---------------------+-------------------------------+
Table 1
Each entry still depends on exact parameter sets, version, and public
review record; a family label alone is insufficient.
NTRU-HPS: NTRU-HPS has NIST PQC public-review history for the
parameter sets in the NTRU Round 3 submission [NTRU-R3]. The main
follow-up item is parameter consistency. The Round 3 submission
contains multiple HPS parameter sets, and draft-fluhrer-cfrg-ntru-
03, an expired individual draft, reports the addition of
ntruhps40961229 [I-D.fluhrer-cfrg-ntru]. As of 2026-06-10, that
draft is no longer active. Security claims need to name exactly
which HPS parameter sets are in scope and map each claim to the
corresponding specification, parameter name, and review record.
NTRU-HRSS: For the NIST-submitted parameter set, NTRU-HRSS has NIST
Liu & Lu Expires 24 December 2026 [Page 23]
Internet-Draft NTRU-family KEM Considerations June 2026
PQC public-review history. The expired individual Internet-Draft
draft-fluhrer-cfrg-ntru-03 is earlier IETF draft work related to
that submission, but it includes additional parameter sets; for
example, it reports the addition of ntruhrss1373
[I-D.fluhrer-cfrg-ntru]. The NTRU specification defines HRSS key-
sampling spaces using T+, where T+ outputs ternary polynomials
satisfying the non-negative correlation property [NTRU-R3].
Because this predicate narrows the sampled support, a security
analysis needs to account for its effect on support size and
entropy when estimating combinatorial and hybrid attacks. That
predicate is an attack-model input. Later HRSS parameter
additions need separate evidence.
Streamlined NTRU Prime: Streamlined NTRU Prime is part of the NTRU
Prime submission, which NIST treated as a third-round alternate
PKE/KEM candidate. NIST did not select NTRU Prime for
standardization or move it to the fourth round [NISTIR8413]. The
sntrup761 instance also has deployment evidence in SSH, including
the Informational RFC for the hybrid method sntrup761x25519-sha512
[RFC9941]. Review still needs to name the Streamlined NTRU Prime
instance in scope and its exact security assumptions, transform,
and correctness model from the authoritative specification.
NTRU+: NTRU+ represents a different evidence category: selection as
a final PKE/KEM algorithm in the Korean Post-Quantum Cryptography
Competition. The cited document is the January 30, 2026 KpqC
final version [NTRU-PLUS]. The evidence category is distinct from
IETF or CFRG approval and from multi-year deployment evidence.
The scheme-specific follow-up is whether the concrete security
estimate for the NTRU layer accounts for the tri-cyclotomic ring
shape.
BAT: BAT is a sampling example for recent NTRU-family designs. It
specifies discrete Gaussian secret-key sampling, so the realized
distribution is a security input, not only an implementation
detail. The analysis should account for the difference between
the nominal Gaussian parameter and the realized discrete standard
deviation, as discussed in the Distribution and Sampling section.
NEV: For NEV, the relevant issue is the ssp RLWE assumption. The
security analysis needs to explain whether it uses the variant
NEV' based on the ssp RLWE assumption rather than standard RLWE,
and provide a concrete security analysis of that assumption.
DAWN: For DAWN, the relevant issue is DFR. The security analysis
should identify where independence assumptions for convolution
coefficients enter the DFR calculation, whether those assumptions
are heuristic, and what conservative fallback bound is available.
Liu & Lu Expires 24 December 2026 [Page 24]
Internet-Draft NTRU-family KEM Considerations June 2026
CTRU and CNTR: CTRU and CNTR are discussed together because the
cited journal article presents both constructions. The article
describes CTRU as relying on NTRU and RLWE assumptions and CNTR as
relying on NTRU and RLWR assumptions. The KEMs use the generic
prefix-hashing FO transform FO^perp_{ID(pk),m} in Duman et al.
[FO-PREFIX-HASHING], while [CTRU-CNTR] is the construction paper
for CTRU and CNTR. Review should separate CTRU from CNTR wherever
the assumption inventory, decoding, rounding, DFR analysis,
transform instantiation, or implementation constraints differ, and
should note the tri-cyclotomic concrete-security check described
in the Structural Attacks section.
Authors' Addresses
Yijian Liu
Institute of Information Engineering, Chinese Academy of Sciences
Beijing
China
Email: icarid.liu@gmail.com
Xianhui Lu
Institute of Information Engineering, Chinese Academy of Sciences
Beijing
China
Email: luxianhui@iie.ac.cn
Liu & Lu Expires 24 December 2026 [Page 25]