<div dir="ltr">I recently had a discussion on this for [1][2] and enabled it in Ubuntu.<div>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.</div><div>Quoting from [3]:</div><div><br></div><div><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">"Enabling the bliss Plugin is probably not such a good idea. There is a potential local side-channel attack on strongSwan's BLISS implementation (<a rel="nofollow" href="https://eprint.iacr.org/2017/505" style="color:rgb(0,51,170);text-decoration-line:none">https://eprint.iacr.org/2017/505</a>).</p><p style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">The ntru plugin should be fine. However, using NTRU with IKEv2 is not standardized (uses an algorithm identifiers from the private use range etc.).</p><p id="gmail-yui_3_10_3_1_1583823522434_1699" style="margin:0px 0px 0.8em;padding:0px;width:auto;max-width:45em;color:rgb(51,51,51);font-family:monospace;font-size:12px">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 (<a rel="nofollow" href="https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization" style="color:rgb(0,51,170);text-decoration-line:none">https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization</a>) and versions of NTRU are among the contenders in round 2 (<a rel="nofollow" href="https://csrc.nist.gov/projects/post-quantum-cryptography/round-2-submissions" style="color:rgb(0,51,170);text-decoration-line:none">https://csrc.nist.gov/projects/post-quantum-cryptography/round-2-submissions</a>). 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, <a rel="nofollow" href="https://github.com/open-quantum-safe/liboqs/" style="color:rgb(0,51,170);text-decoration-line:none">https://github.com/open-quantum-safe/liboqs/</a>)."</p><div><br></div><div>[1]: <a href="https://salsa.debian.org/debian/strongswan/-/merge_requests/8">https://salsa.debian.org/debian/strongswan/-/merge_requests/8</a></div><div>[2]: <a href="https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1863749">https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1863749</a></div><div>[3]: <a href="https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1863749/comments/14">https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1863749/comments/14</a><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Christian Ehrhardt<br>Staff Engineer, Ubuntu Server<br>Canonical Ltd</div></div></div></div>