[CFRG] Re: PQ KEM Security Considerations

[Liu Icarid <[e-mail]>]

Dear Daniel,

Thank you for the comments.

The original plan was to write a DAWN-specific per-KEM security
consideration draft. After an email exchange with Nick, I understood that
DAWN is still quite new and not mature enough for the current
standardization discussion, so I changed direction and tried to write a
broader security consideration draft for NTRU-family KEMs.

I agree that the result is too general in some places. Since the encryption
layer of many NTRU-family constructions is RLWE-like, several issues
naturally overlap with broader lattice-based KEM review. At the same time,
some points in the draft came from concrete NTRU-based schemes, such as the
security of tri-cyclotomic rings and the realized standard deviation of
discrete Gaussian distribution.

My intention was not to introduce another top-down process or delay
concrete KEM analysis, but to provide a reference for people considering
NTRU-family KEMs. I can revise the draft to make this scope clearer and to
move the more general lattice-KEM checklist material out of the main line.

Best,
Yijian

On Tue, Jun 23, 2026 at 7:14 PM D. J. Bernstein <[e-mail]> wrote:

> Liu Icarid writes:
> > In response to the chairs' call for PQ KEM security-considerations and
> > review-criteria documents, we have submitted a related individual draft:
> >   Security Considerations for NTRU-family KEMs
> >   draft-liu-cfrg-ntru-family-security-considerations-00
>
> Is there a reason you're focusing this on the NTRU family (i.e.,
> Quotient NTRU)? The "short quotient in a polynomial ring" part is
> specific to that family but many other parts sound like they're talking
> about a broader range of lattice systems (e.g. "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").
>
> The chart in
>
>     https://ntruprime.cr.yp.to/warnings.html
>
> covers a broader range of lattice systems. The distinction between
> quotients and products is only one aspect of the risk analysis.
>
> > Review and feedback would be welcome, especially on whether this
> > family-level checklist is useful alongside the per-KEM documents
>
> I think there was already a big delay for the chairs to come up with an
> initial top-down checklist, and what would actually make progress at
> this point is analyzing concrete KEM documents. People will naturally
> say "what does this mean for other KEMs?" when relevant (rather than
> repeating the same discussion from scratch for each example); shared
> understanding of the big picture will appear bottom-up. Further delays
> trying to figure things out top-down will inevitably waste time on many
> issues that don't actually matter for any IETF/IRTF KEM decisions.
>
> ---D. J. Bernstein
>
>
> ===== NOTICES =====
>
> IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
> (normative), "Rights in Contributions", provides a modification right
> "unless explicitly disallowed in the notices contained in a Contribution
> (in the form specified by the Legend Instructions)".
>
> The official language from IETF's "Legend Instructions" for the
> situation that "the Contributor does not wish to allow modifications nor
> to allow publication as an RFC" is as follows: "This document may not be
> modified, and derivative works of it may not be created, and it may not
> be published except as an Internet-Draft."
> <
> https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf
> >
>
> The same language is used in, e.g., RFC 5831. The same language hereby
> applies to this document. This is not disclaiming or limiting the
> applicability of IETF policies; it is strictly following IETF policies.
>
> IESG claims that the "explicitly disallowed" provision in BCP 78 is
> limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
> 78 states that Section 5, "Rights in Contributions", is normative, while
> Section 3, "Exposition of Why These Procedures Are the Way They Are", is
> informative. The opt-out provision in the normative text is clear, and
> cannot be limited by an informative section. BCP 78 does not give IESG
> any authority to issue changes or purported clarifications of the rules.
>
> Rationale for exercising the BCP 78 opt-out provision: I'm fine with
> redistribution of copies of this document. The issue is instead with
> modification, such as (1) IESG's May 2025 posting of an IESG-mangled
> version of an appeal that I had filed and (2) IETF management selling
> IETF mailing-list text to AI companies. This goes far beyond what
> copyright law allows as fair use (such as giving quotes for purposes of
> commentary). When I complained about the mangled document, the IETF
> Executive Director responded not by apologizing but instead by asserting
> that IETF management had the power to do whatever it wanted.
>
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>