### Warnings regarding lattice-based cryptography in general

A 2015 algorithm
breaks dimension-N SVP
(under plausible assumptions)
in time 2^{(c+o(1))N} as N→∞
with c≈0.292.
For comparison,
the best algorithm known just five years earlier had a much
worse c≈0.415,
and the best algorithm known just ten years before that took
time 2^{Θ(N log N)}.

Gentry's original FHE system at STOC 2009, with standard "cyclotomic" choices of rings, is now known (again under plausible assumptions) to be broken in polynomial time by a quantum algorithm. Peikert claimed in 2015 that the weakness in Gentry's system was specific to Gentry's short generators and inapplicable to Ideal-SVP:

Although cyclotomics have a lot of structure, nobody has yet found a way to exploit it in attacking Ideal-SVP/BDD ... For commonly used rings, principal ideals are an extremely small fraction of all ideals. ... The weakness here is not so much due to the structure of cyclotomics, but rather to the extra structure of principal ideals that have short generators.

However,
the attack was then combined with further features of cyclotomics
to break Ideal-SVP
(again under plausible assumptions)
with approximation factor 2^{N1/2+o(1)},
a terrifying advance compared to the previous
2^{N1+o(1)}.

As these attack examples illustrate, the security of lattice-based cryptography is not well understood. There are serious risks of further advances in

- SVP algorithms,
- algorithms that exploit the "approximation factors" used in cryptography,
- algorithms that exploit the structure of cryptographic problems such as LWE,
- algorithms that exploit the multiplicative structure
of
*efficient*cryptographic problems such as Ring-LWE, - algorithms that exploit the structure of these problems
for the
*specific*rings chosen by users, and - algorithms to break cryptosystems without breaking these problems.

To eliminate *some* tools used in recent attacks,
we recommend switching
from "NTRU Classic" rings and "NTRU NTT" rings
to "NTRU Prime" rings,
as explained in our paper.
However, we emphasize that lattice-based cryptography
has many other attack avenues that need further study.

### Warnings regarding Streamlined NTRU Prime and NTRU LPRime

Beyond the general warnings above, we issue the following specific warnings to potential users:

- Many details of Streamlined NTRU Prime were first published in May 2016 and require careful security review.
- Many details of NTRU LPRime were first published in December 2017 and require careful security review.
- Second-round tweaks for the CCA transforms for Streamlined NTRU Prime and NTRU LPRime were first published in April 2019. These tweaks are meant to add extra layers of defense but still require careful security review.

### Warnings regarding software in general

Beyond the warnings above regarding the definitions of cryptographic functions, we issue further warnings regarding software meant to implement those functions.

At the moment, the most concise implementations of lattice-based cryptography are implementations in the Sage computer-algebra system. However, these implementations leak secret information through timing.

C implementations are sometimes designed

- to avoid data-dependent branches and array indices (for example, conditional swaps are computed by arithmetic rather than by branches) and
- to avoid other C operations that often take variable time (for example, divisions by 3 are computed via multiplications and shifts).

Our C implementations for NTRU Prime are designed this way.
However,
there are at least some platforms where multiplications take variable time,
and fixing this requires platform-specific effort;
see
`https://www.bearssl.org/ctmul.html`

and
`https://research.tue.nl/en/studentTheses/a-performance-study-of-x25519-on-cortex-m3-and-m4`

.
Furthermore,
C compilers generally do not make any guarantees regarding timing.
Compiled implementations need to be reviewed for constant-time behavior.

Implementations also need to be reviewed for correctness. Our C reference implementations for NTRU Prime are designed to closely match the specification, but this is only the starting point for review; it does not mean that adequate review has taken place. Furthermore, optimized implementations require extra review work. There are many examples of cryptographic software where tests, even quite expensive tests, fail to catch bugs. Some subroutines have been formally verified to work correctly but others have not.

**Version:**This is version 2019.04.11 of the "Warnings" web page.