[strongSwan] Security Comparison

[Christian Salway]

I was just doing some research focusing on the security of the data over a VPN connection - and the chap in the following link has marked OpenVPN, which uses RSA, as being more secure than IKEv2 IPSEC

https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2-protocols/ <https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2-protocols/>

So my question is, in your opinion, do you rate IKEv2 IPSEC more secure than an RSA encrypted VPN like OpenVPN

[Christian Salway]

Hi Robert,

Thank you for coming back to me. I have a client who is pushing for VDI (HTTPS) instead of VPN (IPSEC) and I’m wondering whether there is a security standpoint I can argue or if its just as secure. I am also limited to the native OSX/Windows VPN clients which currently support a maximum of aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not support ecp)

Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should a VPN client be infected with a worm, it is easier for that worm to infect the network, I’m struggling to see another security argument.

Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection. Whereas IKE also uses a certificate to do the KeyExchange before logging in and then encrypting the data with ESP, so the ciphers used on ESP I feel is the comparison that needs to be made.

I will have a read of that Cipher suites page, but if I remember correctly, it is not a comparison but a standpoint.

C

> On 19 Jul 2018, at 05:51, Robert Leonard <***@gmail.com> wrote:
>
> I don't really know where to start with this article. It appears to be sponsored by OpenVPN, and is written from the perspective of a home user, not a security standpoint. I
> I would suggest taking a look at the documentation for the Cipher suites rather than taking this article at face value.
>
> https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites <https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites>
>
> Most importantly, what is your use case?
>
>
>
> On Wed, Jul 18, 2018 at 6:23 PM Christian Salway <***@naimuri.com <mailto:***@naimuri.com>> wrote:
> I was just doing some research focusing on the security of the data over a VPN connection - and the chap in the following link has marked OpenVPN, which uses RSA, as being more secure than IKEv2 IPSEC
>
> https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2-protocols/ <https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2-protocols/>
>
> So my question is, in your opinion, do you rate IKEv2 IPSEC more secure than an RSA encrypted VPN like OpenVPN
>
>
> --
> Rob Leonard
> RJL Contracting
> Cell: (248) 403 4817
> E-Mail: ***@gmail.com <mailto:***@gmail.com>

[Tobias Brunner]

Hi Christian,

> I am also
> limited to the native OSX/Windows VPN clients which currently support a
> maximum of aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not
> support ecp)

It does (at least on Windows 10), you just have to enable it via
PowerShell (see [1]).

> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that
> should a VPN client be infected with a worm, it is easier for that worm
> to infect the network, I’m struggling to see another security argument.

Probably depends on the IPsec policies (e.g. if split tunneling is used
or even only single protocols/ports are allowed) and the firewall rules
on the remote end vs. what is available via HTTPS connection (e.g. if
the latter creates a VPN too or the malware can hijack the VDI somehow).

> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.

Nobody encrypts large amounts of data via RSA, if anything it's used to
encrypt a symmetric key that's then used to encrypt the data, but mostly
only for authentication (digital signatures). The key exchange usually
happens via ephemeral DH (in IKE always and nowadays in TLS too).

>  Whereas IKE also uses a certificate to do the KeyExchange before
> logging in

No, the key exchange is done via DH, the certificate is used for
authentication only (to prevent MITM attacks).

> and then encrypting the data with ESP, so the ciphers used on
> ESP I feel is the comparison that needs to be made.

The cryptographic strength of all ciphers in a cipher suite should be
consistent. For instance, using AES-256 for ESP is basically wasted
when using MODP-2048 because that has only an estimated strength of 112
bits (same for ECP-256 whose estimated strength is 128 bits).

> I will have a read of that Cipher suites page, but if I remember
> correctly, it is not a comparison but a standpoint.

It mainly documents the available options (there are some warnings/notes
though). [2] has some general pointers regarding the security of
IKE/IPsec connections.

Regards,
Tobias

[1]
https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048
[2]
https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

[Christian Salway]

Thanks. answers inline


> On 19 Jul 2018, at 09:38, Tobias Brunner <***@strongswan.org> wrote:
>
> Hi Christian,
>
>> I am also
>> limited to the native OSX/Windows VPN clients which currently support a
>> maximum of aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not
>> support ecp)
>
> It does (at least on Windows 10), you just have to enable it via
> PowerShell (see [1]).

Even with the registry key added, the IKE ciphers are as follows:

WINDOWS 10
IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048

ie, no ECP and annoyingly weakest first!

OSX
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256,
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536,
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024,
IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024


>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that
>> should a VPN client be infected with a worm, it is easier for that worm
>> to infect the network, I’m struggling to see another security argument.
>
> Probably depends on the IPsec policies (e.g. if split tunneling is used
> or even only single protocols/ports are allowed) and the firewall rules
> on the remote end vs. what is available via HTTPS connection (e.g. if
> the latter creates a VPN too or the malware can hijack the VDI somehow).

Split tunneling and select ports, but it is still easier for a worm to go down an IP than over VDI

>
>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.
>
> Nobody encrypts large amounts of data via RSA, if anything it's used to
> encrypt a symmetric key that's then used to encrypt the data, but mostly
> only for authentication (digital signatures). The key exchange usually
> happens via ephemeral DH (in IKE always and nowadays in TLS too).

>
>> Whereas IKE also uses a certificate to do the KeyExchange before
>> logging in
>
> No, the key exchange is done via DH, the certificate is used for
> authentication only (to prevent MITM attacks).
>
>> and then encrypting the data with ESP, so the ciphers used on
>> ESP I feel is the comparison that needs to be made.
>
> The cryptographic strength of all ciphers in a cipher suite should be
> consistent. For instance, using AES-256 for ESP is basically wasted
> when using MODP-2048 because that has only an estimated strength of 112
> bits (same for ECP-256 whose estimated strength is 128 bits).


Clearly the few points above tells me I need to understand how the secure cycle works.. any good websites that can explain HTTPS and IKE/IPSEC?

>
>> I will have a read of that Cipher suites page, but if I remember
>> correctly, it is not a comparison but a standpoint.
>
> It mainly documents the available options (there are some warnings/notes
> though). [2] has some general pointers regarding the security of
> IKE/IPsec connections.
>
> Regards,
> Tobias
>
> [1]
> https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048
> [2]
> https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

[Dirk Hartmann]

--On Thursday, July 19, 2018 09:58:51 AM +0100 Christian Salway
<***@naimuri.com> wrote:

>
> Thanks. answers inline
>
>
>> On 19 Jul 2018, at 09:38, Tobias Brunner <***@strongswan.org>
>> wrote:
>>
>> Hi Christian,
>>
>>> I am also
>>> limited to the native OSX/Windows VPN clients which currently
>>> support a maximum of aes256-sha256-prfsha256-ecp256-modp2048
>>> (Windows does not support ecp)
>>
>> It does (at least on Windows 10), you just have to enable it via
>> PowerShell (see [1]).
>
> Even with the registry key added, the IKE ciphers are as follows:
>
> WINDOWS 10
> IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
> IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048

Have a look here:
<https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps>

Regards,
Dirk

[Christian Salway]

ah! cool. will have to give it a go.


Kind regards,

Christian Salway
IT Consultant - Naimuri

T: [phone]
E: ***@naimuri.com
A: Naimuri Ltd, Capstan House, Manchester M50 2UW

> On 19 Jul 2018, at 10:07, Dirk Hartmann <***@heise.de> wrote:
>
>
>
> --On Thursday, July 19, 2018 09:58:51 AM +0100 Christian Salway <***@naimuri.com <mailto:***@naimuri.com>> wrote:
>
>>
>> Thanks. answers inline
>>
>>
>>> On 19 Jul 2018, at 09:38, Tobias Brunner <***@strongswan.org>
>>> wrote:
>>>
>>> Hi Christian,
>>>
>>>> I am also
>>>> limited to the native OSX/Windows VPN clients which currently
>>>> support a maximum of aes256-sha256-prfsha256-ecp256-modp2048
>>>> (Windows does not support ecp)
>>>
>>> It does (at least on Windows 10), you just have to enable it via
>>> PowerShell (see [1]).
>>
>> Even with the registry key added, the IKE ciphers are as follows:
>>
>> WINDOWS 10
>> IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
>> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
>> IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048
>
> Have a look here:
> <https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps <https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps>>
>
> Regards,
> Dirk

[Christian Salway]

I used

PS C:\> Add-VpnConnection -Name "Contoso" -ServerAddress 176.16.1.2 -TunnelType "Ikev2"
PS C:\> Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso" -AuthenticationTransformConstants None -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 -PfsGroup None -DHGroup ECP384 -PassThru -Force

and the result was:

Jul 19 09:22:24 05[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048, IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048
Jul 19 09:22:24 05[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256/MODP_2048
Jul 19 09:22:24 05[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

ie, still no ECP.



Kind regards,

Christian Salway
IT Consultant - Naimuri

T: [phone]
E: ***@naimuri.com
A: Naimuri Ltd, Capstan House, Manchester M50 2UW

> On 19 Jul 2018, at 10:07, Dirk Hartmann <***@heise.de> wrote:
>
>
>
> --On Thursday, July 19, 2018 09:58:51 AM +0100 Christian Salway <***@naimuri.com <mailto:***@naimuri.com>> wrote:
>
>>
>> Thanks. answers inline
>>
>>
>>> On 19 Jul 2018, at 09:38, Tobias Brunner <***@strongswan.org>
>>> wrote:
>>>
>>> Hi Christian,
>>>
>>>> I am also
>>>> limited to the native OSX/Windows VPN clients which currently
>>>> support a maximum of aes256-sha256-prfsha256-ecp256-modp2048
>>>> (Windows does not support ecp)
>>>
>>> It does (at least on Windows 10), you just have to enable it via
>>> PowerShell (see [1]).
>>
>> Even with the registry key added, the IKE ciphers are as follows:
>>
>> WINDOWS 10
>> IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
>> IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
>> IKE:AES_CBC_256/HMAC_SHA2_384_192/PRF_HMAC_SHA2_384/MODP_2048
>
> Have a look here:
> <https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps <https://docs.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=win10-ps>>
>
> Regards,
> Dirk

[Christian Salway]

Great read on how HTTPS works

https://robertheaton.com/2014/03/27/how-does-https-actually-work/ <https://robertheaton.com/2014/03/27/how-does-https-actually-work/>

From reading that, if a client was only to present a ciphersuite of 3DES (or worse) in the initial ClientHello, then it really doesnt matter how strong the ServerCert is in the handshake because once the Client and Server agree on the algo to use (3DES) and symmetric key, then this is where the strength is.... I feel the world is oblivious to this fact. You can have the strongest ServerCert but unless you have a strong algorithm, it is wasted... right?

So if thats correct, how do you find out what the actual algorithm used for the data messaging is :/ On to my continued studies.



> On 19 Jul 2018, at 09:38, Tobias Brunner <***@strongswan.org> wrote:
>
> Hi Christian,
>
>> I am also
>> limited to the native OSX/Windows VPN clients which currently support a
>> maximum of aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not
>> support ecp)
>
> It does (at least on Windows 10), you just have to enable it via
> PowerShell (see [1]).
>
>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that
>> should a VPN client be infected with a worm, it is easier for that worm
>> to infect the network, I’m struggling to see another security argument.
>
> Probably depends on the IPsec policies (e.g. if split tunneling is used
> or even only single protocols/ports are allowed) and the firewall rules
> on the remote end vs. what is available via HTTPS connection (e.g. if
> the latter creates a VPN too or the malware can hijack the VDI somehow).
>
>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.
>
> Nobody encrypts large amounts of data via RSA, if anything it's used to
> encrypt a symmetric key that's then used to encrypt the data, but mostly
> only for authentication (digital signatures). The key exchange usually
> happens via ephemeral DH (in IKE always and nowadays in TLS too).
>
>> Whereas IKE also uses a certificate to do the KeyExchange before
>> logging in
>
> No, the key exchange is done via DH, the certificate is used for
> authentication only (to prevent MITM attacks).
>
>> and then encrypting the data with ESP, so the ciphers used on
>> ESP I feel is the comparison that needs to be made.
>
> The cryptographic strength of all ciphers in a cipher suite should be
> consistent. For instance, using AES-256 for ESP is basically wasted
> when using MODP-2048 because that has only an estimated strength of 112
> bits (same for ECP-256 whose estimated strength is 128 bits).
>
>> I will have a read of that Cipher suites page, but if I remember
>> correctly, it is not a comparison but a standpoint.
>
> It mainly documents the available options (there are some warnings/notes
> though). [2] has some general pointers regarding the security of
> IKE/IPsec connections.
>
> Regards,
> Tobias
>
> [1]
> https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048
> [2]
> https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

[Christian Salway]

Now I understand how the handshake works (maybe), I used Wireshark to see the cipher suites and the selected one for HTTPS to our companies website

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

As taken from [1] to mean:

TLS - the protocol used
ECDHE - the key exchange mechanism
RSA - the algorithm of the authentication key
AES - the symmetric encryption algorithm
256 - the key size of the above
GCM - the mode of the above
SHA384 - the MAC used by the algorithm

AES_256_GCM being the cipher

This seems like a strong encryption for message data, and dare I say, stronger than the default ciphers available to native VPN clients on OSX and Windows 10. Although both seem adequately strong for todays standards.

[1] https://scotthelme.co.uk/https-cheat-sheet/ <https://scotthelme.co.uk/https-cheat-sheet/>


> On 19 Jul 2018, at 09:38, Tobias Brunner <***@strongswan.org> wrote:
>
> Hi Christian,
>
>> I am also
>> limited to the native OSX/Windows VPN clients which currently support a
>> maximum of aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not
>> support ecp)
>
> It does (at least on Windows 10), you just have to enable it via
> PowerShell (see [1]).
>
>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that
>> should a VPN client be infected with a worm, it is easier for that worm
>> to infect the network, I’m struggling to see another security argument.
>
> Probably depends on the IPsec policies (e.g. if split tunneling is used
> or even only single protocols/ports are allowed) and the firewall rules
> on the remote end vs. what is available via HTTPS connection (e.g. if
> the latter creates a VPN too or the malware can hijack the VDI somehow).
>
>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.
>
> Nobody encrypts large amounts of data via RSA, if anything it's used to
> encrypt a symmetric key that's then used to encrypt the data, but mostly
> only for authentication (digital signatures). The key exchange usually
> happens via ephemeral DH (in IKE always and nowadays in TLS too).
>
>> Whereas IKE also uses a certificate to do the KeyExchange before
>> logging in
>
> No, the key exchange is done via DH, the certificate is used for
> authentication only (to prevent MITM attacks).
>
>> and then encrypting the data with ESP, so the ciphers used on
>> ESP I feel is the comparison that needs to be made.
>
> The cryptographic strength of all ciphers in a cipher suite should be
> consistent. For instance, using AES-256 for ESP is basically wasted
> when using MODP-2048 because that has only an estimated strength of 112
> bits (same for ECP-256 whose estimated strength is 128 bits).
>
>> I will have a read of that Cipher suites page, but if I remember
>> correctly, it is not a comparison but a standpoint.
>
> It mainly documents the available options (there are some warnings/notes
> though). [2] has some general pointers regarding the security of
> IKE/IPsec connections.
>
> Regards,
> Tobias
>
> [1]
> https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048
> [2]
> https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

[Christian Salway]

Hi Noel,

Thank you for adding input. I went away since that email and understood how the initial handshake worked for HTTPS and it all makes sense now. I am not interested in using OpenVPN (in any way). The comparison was to using a Virtual Desktop secured with HTTPS (TLS) to VPN and having an argument to give to the client on which was stronger for data messages.

You have taught me a few points in your last paragraph which is very much appreciated but OpenVPN is not even in question.

Kind regards,

Christian Salway
IT Consultant - Naimuri

T: [phone]
E: ***@naimuri.com
A: Naimuri Ltd, Capstan House, Manchester M50 2UW

> On 20 Jul 2018, at 12:27, Noel Kuntze <noel.kuntze+strongswan-users-***@thermi.consulting> wrote:
>
> Hello Christian,
>
> I have some more points to make, additionally to what you already discussed with Tobias.
>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should a VPN client be infected with a worm, it is easier for that worm to infect the network, I’m struggling to see another security argument.
> That is entirely irrelevant and wrong. OpenVPN just puts the IP packets in its own transport protocoll, which to the outside looks like TLS, but it's _not_ TLS. They implemented their own handshake. Also, there is not a single bit of HTTP in it and the layer differentiation here is irrelevant. Both are layer three VPNs. IPsec can also work as a layer 4 VPN, if you use transport mode. Thus any difference is irrelevant for any kind of malicious software trying to attack over the/a VPN.
>
>>
>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection. Whereas IKE also uses a certificate to do the KeyExchange before logging in and then encrypting the data with ESP, so the ciphers used on ESP I feel is the comparison that needs to be made.
> As Tobias already work, that's not what is happening. RSA is extremely slow compared to symmetric ciphers. RSA is only used for proving the identity of the peers by use of signing and verification of a signature. DH or ECDH is used for the key exchange. After that, symmetric ciphers and HMACs or AEAD algorithms are used for encryption and authentication. IPsec is historically stronger than TLS, because it does not use Mac-Then-Encrypt, which TLS does. That lead to attacks like Bleichenbacher's attack where the error handling with invalid padding (and other data) in the handshakes leads to vulnerabilities that can be used to decrypt data. IPsec uses Encrypt-Then-Mac. Attacks like Bleichenbacher's don't work on IPsec.
>
> Kind regards
>
> Noel
>
> On 19.07.2018 09:33, Christian Salway wrote:
>> Hi Robert,
>>
>> Thank you for coming back to me. I have a client who is pushing for VDI (HTTPS) instead of VPN (IPSEC) and I’m wondering whether there is a security standpoint I can argue or if its just as secure. I am also limited to the native OSX/Windows VPN clients which currently support a maximum of aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not support ecp)
>>
>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should a VPN client be infected with a worm, it is easier for that worm to infect the network, I’m struggling to see another security argument.
>>
>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection. Whereas IKE also uses a certificate to do the KeyExchange before logging in and then encrypting the data with ESP, so the ciphers used on ESP I feel is the comparison that needs to be made.
>>
>> I will have a read of that Cipher suites page, but if I remember correctly, it is not a comparison but a standpoint.
>>
>> C
>>
>>> On 19 Jul 2018, at 05:51, Robert Leonard <***@gmail.com <mailto:***@gmail.com> <mailto:***@gmail.com <mailto:***@gmail.com>>> wrote:
>>>
>>> I don't really know where to start with this article. It appears to be sponsored by OpenVPN, and is written from the perspective of a home user, not a security standpoint. I
>>> I would suggest taking a look at the documentation for the Cipher suites rather than taking this article at face value.
>>>
>>> https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites <https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites>
>>>
>>> Most importantly, what is your use case?
>>>
>>>
>>>
>>> On Wed, Jul 18, 2018 at 6:23 PM Christian Salway <***@naimuri.com <mailto:***@naimuri.com> <mailto:***@naimuri.com <mailto:***@naimuri.com>>> wrote:
>>>
>>> I was just doing some research focusing on the security of the data over a VPN connection - and the chap in the following link has marked OpenVPN, which uses RSA, as being more secure than IKEv2 IPSEC
>>>
>>> https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2-protocols/ <https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2-protocols/>
>>>
>>> So my question is, in your opinion, do you rate IKEv2 IPSEC more secure than an RSA encrypted VPN like OpenVPN
>>>
>>>
>>>
>>> --
>>> Rob Leonard
>>> RJL Contracting
>>> Cell: (248) 403 4817
>>> E-Mail: ***@gmail.com <mailto:***@gmail.com> <mailto:***@gmail.com <mailto:***@gmail.com>>

[Marco Berizzi]

Hi Tobias,

I think this is an underestimated point. Deserves more attention.

> The cryptographic strength of all ciphers in a cipher suite should be
> consistent. For instance, using AES-256 for ESP is basically wasted
> when using MODP-2048 because that has only an estimated strength of 112
> bits (same for ECP-256 whose estimated strength is 128 bits).

Adding your above remark to [3] would be extremely useful.

According to this paper [1] MODP-1536 is broken (< 112 bits of security
strength), and according to this nist publication [2], the only way to
be consistent with AES-256 is ECP-521 (diffie hellmann group 21) or x25519
(diffie hellmann group 31).

The MODP-3072 or ECP-256 is the minimum for being consistent with AES-128.

So a simple consistent table could be:

AES-128 ==>> MODP-3072 or ECP-256
AES-192 ==>> MODP-8192 or ECP-384
AES-256 ==>> ECP521 or x25519

[1] https://csrc.nist.gov/csrc/media/publications/sp/800-131a/rev-1/final/documents/sp800-131a_r1_draft.pdf
[2] https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf
[3] https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

[Andreas Steffen]

Hi Marco,

actually X25519 DH group 31 has a security strength of 128 bits, similar
to ECP-256, although the Curve25519 characteristics are much better
than those of the ECP-256 NIST curve.

The "Goldilocks" X448 (DH group 32) has a security strength of 224 bits
which is half-way between 192 bits and 256 bits. strongSwan doesn't
support X448 yet.

Best regards

Andreas

On 20.07.2018 14:43, Marco Berizzi wrote:
> Hi Tobias,
>
> I think this is an underestimated point. Deserves more attention.
>
>> The cryptographic strength of all ciphers in a cipher suite should be
>> consistent. For instance, using AES-256 for ESP is basically wasted
>> when using MODP-2048 because that has only an estimated strength of 112
>> bits (same for ECP-256 whose estimated strength is 128 bits).
>
> Adding your above remark to [3] would be extremely useful.
>
> According to this paper [1] MODP-1536 is broken (< 112 bits of security
> strength), and according to this nist publication [2], the only way to
> be consistent with AES-256 is ECP-521 (diffie hellmann group 21) or x25519
> (diffie hellmann group 31).
>
> The MODP-3072 or ECP-256 is the minimum for being consistent with AES-128.
>
> So a simple consistent table could be:
>
> AES-128 ==>> MODP-3072 or ECP-256
> AES-192 ==>> MODP-8192 or ECP-384
> AES-256 ==>> ECP521 or x25519
>
> [1] https://csrc.nist.gov/csrc/media/publications/sp/800-131a/rev-1/final/documents/sp800-131a_r1_draft.pdf
> [2] https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf
> [3] https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations
>

--
======================================================================
Andreas Steffen ***@strongswan.org
strongSwan - the Open Source VPN Solution! www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[INS-HSR]==

[Marco Berizzi]

Hi Andreas,

> actually X25519 DH group 31 has a security strength of 128 bits, similar
> to ECP-256, although the Curve25519 characteristics are much better
> than those of the ECP-256 NIST curve.

thanks for the correction.