In private network (as in using a private IP address space) at a cloud provider, other customers have access to the same private network. I have secured the communication between many hosts and services with TLS provided by Stunnel.

Background: Current Stunnel Configuration

To simplify the current situation, let us focus on the communication between two nodes, A (IP address IP_A) and B (IP_B). An example of the Stunnel, from host A:

; [ This config only shows the crypto-relevant parts ]

; Disable support for insecure SSLv2 protocol and low-strength ciphers
ciphers = TLSv1.2:TLSv1.1:TLSv1:SSLv3:!SSLv2:!SSLv1:!LOW:!eNULL:!aNULL:!ADH:!EXP:!MD5@STRENGTH
sslVersion = TLSv1

; The following options provide additional security at some performance penalty
; Default ECDH/DH parameters are strong/conservative, so it is quite safe to
; comment out these lines in order to get a performance boost
options = SINGLE_DH_USE

verify = 2

client = yes
accept =
connect = IP_B:15675
CApath = /etc/stunnel/ssl/my-service/certs
CRLfile = /etc/stunnel/ssl/my-service/ca-crl.pem
cert = /etc/stunnel/ssl/my-service/certs/my-service-cert.pem
key = /etc/stunnel/ssl/my-service/private/my-service-key.pem

The Stunnel configuration on host B is identical, except that the service section has been replaced by:

client = no
accept = IP_B:15675
connect = localhost:15674
; [ … the key and certificates are the same … ]

The certificates use a 2048 bit RSA key. When I include debugging output in the log, Stunnel reports

Could not load DH parameters from /etc/stunnel/ssl/my-service/certs/my-service-cert.pem
Using hardcoded DH parameters
DH initialized with 2048-bit key
ECDH initialized with curve prime256v1

during startup. Furthermore, when host A connects, the log includes the entries

SSL accepted: new session negotiated
Negotiated TLSv1/SSLv3 ciphersuite: ECDHE-RSA-AES256-SHA (256-bit encryption)


Now, I wonder what IPSec configuration will provide the same level of transport security as the above TLS/Stunnel configuration, both with respect to encryption algorithms and keys used for IPSec authentication headers (AH), encapsulating security payload (ESP), and security policies? I know that IPSec protects all network traffic between the affected hosts, while TLS only protects traffic for the configured ports/applications, so that's not what I'm asking about.

According to the setkey(8) man page, the authentication algorithms available for AH are:

algorithm       keylen (bits)
hmac-md5        128             ah: rfc2403
                128             ah-old: rfc2085
hmac-sha1       160             ah: rfc2404
                160             ah-old: 128bit ICV (no document)
keyed-md5       128             ah: 96bit ICV (no document)
                128             ah-old: rfc1828
keyed-sha1      160             ah: 96bit ICV (no document)
                160             ah-old: 128bit ICV (no document)
null            0 to 2048       for debugging
hmac-sha256     256             ah: 96bit ICV
                256             ah-old: 128bit ICV (no document)
hmac-sha384     384             ah: 96bit ICV (no document)
                384             ah-old: 128bit ICV (no document)
hmac-sha512     512             ah: 96bit ICV (no document)
                512             ah-old: 128bit ICV (no document)
hmac-ripemd160  160             ah: 96bit ICV (RFC2857)
                                ah-old: 128bit ICV (no document)
aes-xcbc-mac    128             ah: 96bit ICV (RFC3566)
                128             ah-old: 128bit ICV (no document)
tcp-md5         8 to 640        tcp: rfc2385 (tcp-md5 support only on BSD)

and the encryption algorithms available for ESP are:

algorithm       keylen (bits)
des-cbc         64              esp-old: rfc1829, esp: rfc2405
3des-cbc        192             rfc2451
null            0 to 2048       rfc2410
blowfish-cbc    40 to 448       rfc2451
cast128-cbc     40 to 128       rfc2451
des-deriv       64              ipsec-ciph-des-derived-01
3des-deriv      192             no document
rijndael-cbc    128/192/256     rfc3602
twofish-cbc     0 to 256        draft-ietf-ipsec-ciph-aes-cbc-01
aes-ctr         160/224/288     draft-ietf-ipsec-ciph-aes-ctr-03
camellia-cbc    128/192/256     rfc4312

Note that the first 128 bits of a key for aes-ctr will be used as AES
key, and the remaining 32 bits will be used as nonce.

Of course, in the event that that several combinations of AH and ESP algorithms and key lengths provide an equivalent level of security as the above STunnel configuration, I would like to optimize for higher bandwidth and lower CPU-usage.

Furthermore, is there a list of (roughly) equivalent TLS and IPSec configuration pairs (algorithms and key lengths)?


When I wrote "level of security" above, I should probably have been more specific and referred to a concept like "security strength", or "bits of security", as defined by The U.S. National Institute of Standards and Technology (NIST) in NIST Special Publication 800-57: Recommendation for Key Management – Part 1: General (Revision 3):

A number associated with the amount of work (that is, the number of operations) that is required to break a cryptographic algorithm or system. In this Recommendation, the security strength is specified in bits and is a specific value from the set {80, 112, 128, 192, 256}

However, please note that bits of security is not (necessarily) equal to the key length used for a particular cipher. Furthermore, in Section "5.6.1 Comparable Algorithm Strengths", they note (emphasis added by me):

[...] two algorithms are considered to be of comparable strength for the given key sizes (X and Y) if the amount of work needed to “break the algorithms” or determine the keys (with the given key sizes) is approximately the same using a given resource. The security strength of an algorithm for a given key size is traditionally described in terms of the amount of work it takes to try all keys for a symmetric algorithm with a key size of "X" that has no short cut attacks (i.e., the most efficient attack is to try all possible keys).

Therefore, when I asked for what IPSec configuration will provide the same level of transport security as the above TLS/Stunnel configuration, the answer should probably depend on the encryption strength of the cipher negotiated by Stunnel, as mentioned above, combined with any knowledge of how the IPSec security model vs the TLS security model might affect the effectiveness of the cipher and/or the overall transport security.

1 Answer 1


Now, I wonder what IPSec configuration will provide the same level of transport security as the above TLS/Stunnel configuration, both with respect to

Blindly looking for "the same level" between two completely different technologies is more or less an opinion - I'm not aware of a single, comprehensive set of meaningful measurements that exist, much less one that has even a chance of giving an identical result.

encryption algorithms and keys used for IPSec authentication headers (AH),

From the list you provided, I'm going to guess that stunnel's ECDHE-RSA-AES256-SHA is likely most equivalent to hmac-sha1. I would recommend moving to at least hmac-sha256.

encapsulating security payload (ESP)

From the list you provided, stunnel's ECDHE-RSA-AES256-SHA is most equivalent to aes-ctr with a length of 288. If you're in Europe or Japan, you should probably substitute camellia-cbc with a length of 256, as camellia variants are their standards.

and security policies?

I cannot answer that part, I'm sorry, as I usually use OpenVPN instead.

  • I've now updated the question in response to your answer regarding how one could compare the strength of two cryptographic algorithms. The concept of security strength should be applicable to both IPSec and TLS, but other factors might need to be taken into account too. Do you have an explanation, or reference to some external source, to why "ECDHE-RSA-AES256-SHA is most equivalent to aes-ctr with a length of 288"? Commented Feb 10, 2014 at 23:21
  • "AES256" in the stunnel ciphersuite refers to AES-256. In particular, it likely refers to AES-256 in CBC mode. AES-CTR is the only AES listed in your IPSec listing; 288 is 256+32, which matches the "remaining 32 bits will be used as nonce" verbiage at the end of the IPSec listing. Thus, AES-CTR with length 288 is AES-256, CTR mode, plus a 32 bit nonce. Commented Feb 11, 2014 at 1:53
  • Note that the OpenVPN ciphersuite "ECDHE-RSA-AES256-SHA" translates to the IANA ciphersuite "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA", which is how CBC mode can be determined. AES-256 has the same "bits" of security as AES-256, and SHA-1 is identical in both cases at (less than) 80 bits. SHA-256, SHA-384, and SHA-512 are all superior to the SHA-1 you're using with stunnel at this time. Commented Feb 11, 2014 at 2:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .