--- Please enter the report below this line. ---
Dear maintainers,

The NTRU and BLISS post-quantum cryptosystems are available in strongswan
(releases 5.1.2 and 5.2.2, respectively).

Please enable the corresponding --enable-ntru and --enable-bliss configure
flags.  Including 5.2.2 in the next point-release would be appreciated too,
though a backport might be more relevant in that case: in 5.3, Strongswan
switched to the BLISS-B variant (with a global config option to revert to
BLISS).


Best,

  nicoo

There's a lot of stuff available in strongSwan. We don't actually enable
everything, on purpose.

Could you elaborate on that? Why would we do that? (besides “to provide those
plugins“)

Point release update won't happen. I can't talk about backports, I'm not
interested in them right now.

Regards,

I'm not sure I want to debate about the security of DH, ECDH and other key-
exchange mechanisms (and especially for passive attackers), but I'm not really
a huge fan of enabling more code to an already quite complex stack.

In any case, if we decide to enable this, it'll be in the extra plugins binary
package.

Regards,

Hello,

Post-quantum key-exchange, as provided by NTRU, is needed by users who want to provide
forward-secrecy in the mid/long-term, given that quantum computers might become a legitimate
threat within the next 5 or 10 years (and we are aware that some people do collect and save
traffic for later cryptanalysis).

BLISS, while potentially nice-to-have, is (in my opinion) less of an immediate concern given the
unlikelyhood of the signature schemes currently-available in strongswan being broken.  The
difference here being that migrating to safer signature scheme might happen as needed (modulo the
time required to deploy new configuration), whereas future threat against the encryption
(including key-exchange) threaten the forward-secrecy of traffic being currently exchanged.
Ok.


Best regards,

  nicoo

Hello,

I am also interested in the NTRU key exchange algorithm for the same
reasons Nicolas Braud-Santoni explains.  Prior to realizing that this
bug existed, I had tested the strongswan with the attached patch which
enables additional plugins.

Note that I enabled BLISS but have no intention of using it due to the
requirement have having to redeploy certificates.

Also note that I enabled ChaCha20/Poly1305, which would be interesting
to use on systems which don't have AES-NI CPU instructions, but
unfortunuately I do not have enough hosts running a 4.2 kernel so I
cannot test this cipher at the moment.  FYI, Linux 4.2 is required to
use this cipher, otherwise error "received netlink error: Function not
implemented (38)" occurs while adding SAD entries.  Very similar to the
problem of enabling AES-GCM-256 on kernels older than ~4.1.

Finally note that I enabled SHA3 but hadn't tested with it because I'm
using AEAD ciphers exclusively.

Let me know if it would be at all useful for me to clean up the patch
such that it only enables NTRU.

In an out-of-band conversation with corsac, it appeared that I didn't
  make my point clearly enough, so here is a recap:

- It is known that nation-state adversaries, interested in mass
  surveillance, are currently recording encrypted traffic they observe,
  in the hope of being able to decrypt it in the future (by obtaining
  the keys or through cryptanalytic means).
- Currently available key exchange mechanisms are all broken by a
  passive, quantum adversary.
- Hence, the forward-secrecy of **currently-transmitted traffic** lasts
  at most as long as nation-state adversaries do not obtain quantum
  computers.
- While quantum computers do not exist yet [0], estimates on the time
  before discovery vary wildly, from 5 to 50 years.


In that light, having a post-quantum kex makes sense.  The NTRU scheme
  has been first formulated 20 years ago and has withstood serious
  scrutiny.  Interestingly, the PQCRYPTO workgroup spoke is evaluating
  the Stehle–Steinfeld variant (not the one available in StrongSwan)
  for long-term security [1].


Note that this is purely about making future mass surveillance, assisted
  by quantum computers, more costly.  This isn't about targeted
  attacks against a specific IPSec deployment (where the situation is
  much more complex, and endpoint security plays a more prevalent role).


[0]: The DWave machines are quantum annealers, and aren't known to be
     able to run Shor's or Grover's algorithms, nor any other
     algorithm relevant for cryptanalysis.

[1]: http://pqcrypto.eu.org/docs/initial-recommendations.pdf

Hi, this is a cleanup of the previously submitted patch.  The mgf1
plugin was added in 5.5.1 and is a dependency of bliss (and newhope)
plugins.  I removed chapoly from the patch as it has it's own bug report
(bug #814927).  FYI newhope, another post-quantum key exchange
algorithm, was added in 5.5.1, but I'll be opening a separate bug
report/patch.
---
 debian/control                             |  4 ++++
 debian/libstrongswan-extra-plugins.install | 11 +++++++++++
 debian/rules                               |  2 ++
 3 files changed, 17 insertions(+)

diff --git a/debian/control b/debian/control
index 59e08ce9..a7d84fd7 100644
--- a/debian/control
+++ b/debian/control
@@ -140,6 +140,8 @@ Description: strongSwan utility and crypto library (extra plugins)
  Included plugins are:
   - af-alg [linux] (AF_ALG Linux crypto API interface, provides
     ciphers/hashers/hmac/xcbc)
+  - bliss (Bimodal Lattice Signature Scheme (BLISS) post-quantum computer
+    signature scheme)
   - ccm (CCM cipher mode wrapper)
   - cmac (CMAC cipher mode wrapper)
   - ctr (CTR cipher mode wrapper)
@@ -147,7 +149,9 @@ Description: strongSwan utility and crypto library (extra plugins)
   - gcrypt (Crypto backend based on libgcrypt, provides
     RSA/DH/ciphers/hashers/rng)
   - ldap (LDAP fetching plugin based on libldap)
+  - mgf1 (MGF1 mask generation function)
   - mysql (MySQL database backend based on libmysqlclient)
+  - ntru (Key exchange based on post-quantum computer NTRU encryption)
   - padlock (VIA padlock crypto backend, provides AES128/SHA1)
   - pkcs11 (PKCS#11 smartcard backend)
   - rdrand (High quality / high performance random source using the Intel
diff --git a/debian/libstrongswan-extra-plugins.install b/debian/libstrongswan-extra-plugins.install
index e5f8baac..6bd32976 100644
--- a/debian/libstrongswan-extra-plugins.install
+++ b/debian/libstrongswan-extra-plugins.install
@@ -1,37 +1,48 @@
 # libstrongswan plugins
+usr/lib/ipsec/plugins/libstrongswan-bliss.so
 usr/lib/ipsec/plugins/libstrongswan-ccm.so
 usr/lib/ipsec/plugins/libstrongswan-cmac.so
 usr/lib/ipsec/plugins/libstrongswan-ctr.so
 usr/lib/ipsec/plugins/libstrongswan-curl.so
 usr/lib/ipsec/plugins/libstrongswan-gcrypt.so
 usr/lib/ipsec/plugins/libstrongswan-ldap.so
+usr/lib/ipsec/plugins/libstrongswan-mgf1.so
 usr/lib/ipsec/plugins/libstrongswan-mysql.so
+usr/lib/ipsec/plugins/libstrongswan-ntru.so
 usr/lib/ipsec/plugins/libstrongswan-pkcs11.so
 usr/lib/ipsec/plugins/libstrongswan-sqlite.so
 usr/lib/ipsec/plugins/libstrongswan-test-vectors.so
 usr/lib/ipsec/plugins/libstrongswan-unbound.so
 # default configuration files
+usr/share/strongswan/templates/config/plugins/bliss.conf
 usr/share/strongswan/templates/config/plugins/ccm.conf
 usr/share/strongswan/templates/config/plugins/cmac.conf
 usr/share/strongswan/templates/config/plugins/ctr.conf
 usr/share/strongswan/templates/config/plugins/curl.conf
 usr/share/strongswan/templates/config/plugins/gcrypt.conf
 usr/share/strongswan/templates/config/plugins/ldap.conf
+usr/share/strongswan/templates/config/plugins/mgf1.conf
 usr/share/strongswan/templates/config/plugins/mysql.conf
+usr/share/strongswan/templates/config/plugins/ntru.conf
 usr/share/strongswan/templates/config/plugins/pkcs11.conf
 usr/share/strongswan/templates/config/plugins/sqlite.conf
 usr/share/strongswan/templates/config/plugins/test-vectors.conf
 usr/share/strongswan/templates/config/plugins/unbound.conf
 usr/share/strongswan/templates/database/sql/mysql.sql
 usr/share/strongswan/templates/database/sql/sqlite.sql
+etc/strongswan.d/charon/bliss.conf
 etc/strongswan.d/charon/ccm.conf
 etc/strongswan.d/charon/cmac.conf
 etc/strongswan.d/charon/ctr.conf
 etc/strongswan.d/charon/curl.conf
 etc/strongswan.d/charon/gcrypt.conf
 etc/strongswan.d/charon/ldap.conf
+etc/strongswan.d/charon/mgf1.conf
 etc/strongswan.d/charon/mysql.conf
+etc/strongswan.d/charon/ntru.conf
 etc/strongswan.d/charon/pkcs11.conf
 etc/strongswan.d/charon/sqlite.conf
 etc/strongswan.d/charon/test-vectors.conf
 etc/strongswan.d/charon/unbound.conf
+# support libs
+usr/lib/ipsec/libnttfft.so*
diff --git a/debian/rules b/debian/rules
index 08c8aa09..d99b21c6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -7,6 +7,7 @@ CONFIGUREARGS := --libdir=/usr/lib --libexecdir=/usr/lib \
 		--enable-addrblock \
 		--enable-agent \
 		--enable-attr-sql \
+		--enable-bliss \
 		--enable-ccm \
 		--enable-certexpire \
 		--enable-cmd \
@@ -32,6 +33,7 @@ CONFIGUREARGS := --libdir=/usr/lib --libexecdir=/usr/lib \
 		--enable-lookip \
 		--enable-mediation \
 		--enable-mysql \
+		--enable-ntru \
 		--enable-openssl \
 		--enable-pkcs11 \
 		--enable-sqlite \
-- 
Gerald Turner <gturner@unzane.com>        Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80  3858 EC94 2276 FDB8 716D

I recently had a discussion on this for [1][2] and enabled it in Ubuntu.
Out of that I'd want to let you know what upstream (Thanks Tobias) let me
know about it as it would matter for this bug here as well.
Quoting from [3]:

"Enabling the bliss Plugin is probably not such a good idea. There is a
potential local side-channel attack on strongSwan's BLISS implementation (
https://eprint.iacr.org/2017/505).

The ntru plugin should be fine. However, using NTRU with IKEv2 is not
standardized (uses an algorithm identifiers from the private use range
etc.).

Multiple IKEv2 protocol extensions are currently being developed, for
instance, additional exchanges to use fragmentation during the key exchange
or using multiple and more generic key exchanges, in particular,
post-quantum key encapsulation mechanisms (KEM, of which most have quite
large public keys). The latter (plus signature algorithms) are currently
being standardized by NIST (
https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization)
and versions of NTRU are among the contenders in round 2 (
https://csrc.nist.gov/projects/post-quantum-cryptography/round-2-submissions).
BLISS is not, but CRYSTALS-DILITHIUM is designed by the same people. It
might be a while until strongSwan supports the protocol extensions (there
is a branch with a partial implementation) and especially the new
algorithms (we currently use the liboqs library in said branch,
https://github.com/open-quantum-safe/liboqs/)."

[1]: https://salsa.debian.org/debian/strongswan/-/merge_requests/8
[2]: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1863749
[3]:
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1863749/comments/14

Hello,


I see the last update to this bug was in 2020. A lot of things happened
regarding PQC in that time, including the finalised standardisation of
ML-KEM.

The strongswan Android app already supports ML-KEM and strongswan 6
server itself also does in principle, with a simple flag (  --enable-ml
             enable Module-Lattice-based crypto (ML-KEM) plugin.
)

With client and server having the same algorithm suite configured, they
agree, but then:

charon: 14[IKE] negotiated key exchange method ML_KEM_768 not supported

Since the client sends the corresponding proposal, it looks very much
like the server lacks compiled-in support for ML-KEM.

Is there still a reason in 2026 not to include PQC support?


Greetings,


Stefan Winter

Hi Stefan,

Please refer to Bug#1121988 [1].

Regards,
Tobias

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121988