Package: strongswan
Severity: wishlist
X-Debbugs-CC: [email protected]
--- 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
Acknowledgement sent
to Yves-Alexis Perez <[email protected]>:
Extra info received and forwarded to list. Copy sent to strongSwan Maintainers <[email protected]>.
(Mon, 02 Nov 2015 20:09:19 GMT) (full text, mbox, link).
On lun., 2015-11-02 at 20:36 +0100, Nicolas Braud-Santoni wrote:
> The NTRU and BLISS post-quantum cryptosystems are available in strongswan
> (releases 5.1.2 and 5.2.2, respectively).
There's a lot of stuff available in strongSwan. We don't actually enable
everything, on purpose.
>
> Please enable the corresponding --enable-ntru and --enable-bliss configure
> flags.
Could you elaborate on that? Why would we do that? (besides “to provide those
plugins“)
> 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).
Point release update won't happen. I can't talk about backports, I'm not
interested in them right now.
Regards,
--
Yves-Alexis
Acknowledgement sent
to Yves-Alexis Perez <[email protected]>:
Extra info received and forwarded to list. Copy sent to strongSwan Maintainers <[email protected]>.
(Tue, 03 Nov 2015 16:03:08 GMT) (full text, mbox, link).
On mar., 2015-11-03 at 16:56 +0100, Nicolas Braud-Santoni wrote:
> 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).
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,
--
Yves-Alexis
Acknowledgement sent
to Nicolas Braud-Santoni <[email protected]>:
Extra info received and forwarded to list. Copy sent to strongSwan Maintainers <[email protected]>.
(Tue, 03 Nov 2015 16:03:17 GMT) (full text, mbox, link).
Hello,
On Mon, Nov 02, 2015 at 09:06:38PM +0100, Yves-Alexis Perez wrote:
> On lun., 2015-11-02 at 20:36 +0100, Nicolas Braud-Santoni wrote:
> > The NTRU and BLISS post-quantum cryptosystems are available in strongswan
> > (releases 5.1.2 and 5.2.2, respectively).
>
> There's a lot of stuff available in strongSwan. We don't actually enable
> everything, on purpose.
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.
> Point release update won't happen. I can't talk about backports, I'm not
> interested in them right now.
Ok.
Best regards,
nicoo
Acknowledgement sent
to Gerald Turner <[email protected]>:
Extra info received and forwarded to list. Copy sent to strongSwan Maintainers <[email protected]>.
(Mon, 30 Nov 2015 21:45:07 GMT) (full text, mbox, link).
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.
--
Gerald Turner <[email protected]> Encrypted mail preferred!
OpenPGP: 4096R / CA89 B27A 30FA 66C5 1B80 3858 EC94 2276 FDB8 716D
Acknowledgement sent
to Nicolas Braud-Santoni <[email protected]>:
Extra info received and forwarded to list. Copy sent to strongSwan Maintainers <[email protected]>.
(Sun, 21 Feb 2016 17:03:15 GMT) (full text, mbox, link).
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
Acknowledgement sent
to Gerald Turner <[email protected]>:
Extra info received and forwarded to list. Copy sent to strongSwan Maintainers <[email protected]>.
(Sun, 23 Apr 2017 22:21:03 GMT) (full text, mbox, link).
Acknowledgement sent
to Christian Ehrhardt <[email protected]>:
Extra info received and forwarded to list. Copy sent to strongSwan Maintainers <[email protected]>.
(Tue, 10 Mar 2020 07:06:03 GMT) (full text, mbox, link).
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.