xelerance/Openswan

esp=aes_gcm_a256-md5 doesn't work

Closed this issue · 10 comments

AnatoliChe commented

Hi!
If I have esp=aes_gcm_a256-md5 in conn (on the both sides) I have got:
118 "conn1" #143: STATE_QUICK_I1: initiate
010 "conn1" #143: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "conn1" #143: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "conn1" #143: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal

With esp=aes256-md5 everything is ok

ipsec auto --version
2.6.51.3

With GCM:
002 "conn1" #142: initiating Main Mode
105 "conn1" #142: STATE_MAIN_I1: initiate
003 "conn1" #142: received Vendor ID payload [Openswan (this version) 2.6.51.3 ]
003 "conn1" #142: received Vendor ID payload [Dead Peer Detection]
002 "conn1" #142: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
107 "conn1" #142: STATE_MAIN_I2: sent MI2, expecting MR2
002 "conn1" #142: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
109 "conn1" #142: STATE_MAIN_I3: sent MI3, expecting MR3
003 "conn1" #142: received Vendor ID payload [CAN-IKEv2]
002 "conn1" #142: Main mode peer ID is ID_FQDN: 'host1'
002 "conn1" #142: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
004 "conn1" #142: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG oursig= theirsig=AQN2EwF/B cipher=aes_128 prf=oakley_sha group=modp1536}
002 "conn1" #142: Dead Peer Detection (RFC 3706): enabled
002 "conn1" #143: initiating Quick Mode RSASIG+ENCRYPT+PFS+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#142 msgid:7b4f8ea4 proposal=none pfsgroup=OAKLEY_GROUP_MODP1536}
118 "conn1" #143: STATE_QUICK_I1: initiate
010 "conn1" #143: STATE_QUICK_I1: retransmission; will wait 20s for response
010 "conn1" #143: STATE_QUICK_I1: retransmission; will wait 40s for response
031 "conn1" #143: max number of retransmissions (2) reached STATE_QUICK_I1. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
000 "conn1" #143: starting keying attempt 2 of an unlimited number, but releasing whack

letoams commented

doesn't openswan still have that weird thing where icv bits are added to the keysize specified ?
(I can't confirm because the man page doesnt list gcm at all, and their test cases seem to be secret now). try not specifying a key size

AnatoliChe commented

It wont help.
But yes with keys len it's a little bit weird.
Let's say you can use ESP_AES_CTR, ivlen=8, keysizemin=160, keysizemax=288
With Libreswan it can be 128, 256.
And I wont be able to make connection between OSW and LSW with AES_CTR.
Only aes128-sha1.
LSW has hw_off.
But with OSW I can make aes128-null or esp=aes_ctr160-null;modp1024 and it's much faster then everything I can make to connect LSW to OSW.
I spent alot time for tests. Even rewrite tool to convert ipsec.secret to nss :-D

letoams commented
AnatoliChe commented

--impair-allow-null-none

Thank you. I should read manuals :- ( It's my fault.

modp1024 is also rejected

Got it.

I don't know what you are trying to do

I want 25G point-to point security channel. And need 10G at least.
Whis sha1 2.5G is limit (
I believe Swan needs something like to XXH64 http://cyan4973.github.io/xxHash/ it will be possible calc hash with speed of memory.

Using -null for integrity defeats the whole security of the VPN.

I was pretty sure, If I use

ike=aes-sha1
esp=aes-null

no one can steal keys or decrypt traffic.
But man in the middle can send his own ESP and ipsec will decrypt this ESP to some corrupted bytes.

letoams commented
AnatoliChe commented

If you insist on encryption without authentication

I do not insist. I try to understand and aware of my incompetence.

I was sure oracle attack not problem for AES_GCM. 'cause CGM/CTR do not have padding. And CGM/AES_GMAC are authenticated encryption algorithms and do not need any additional hash.

Thank you for spending your time. It is very kind from you and really usefull.

letoams commented
AnatoliChe commented

But I thought you couldn’t interop between libreswan and openswan
Even more I can not connect OSW(AES-GCM) <= = > (AES-GCM)OSW
I tried in both sides all combinations
aes_gcm_(abc)_(128|160|256|288)-(null|sha|md5);modp(1024|1536|2048)
and can't connect OSW to OSW.

But with
aes_ctr160-null;modp2048 (and aes_ctr160-sha1l;modp2048 ) I can connect OSW to OSW but cannot CONNECT OSW to LSW.

000 algorithm ESP encrypt: id=18, name=ESP_AES_GCM_A, ivlen=8, keysizemin=160, keysizemax=288 000 algorithm ESP encrypt: id=19, name=ESP_AES_GCM_B, ivlen=12, keysizemin=160, keysizemax=288 000 algorithm ESP encrypt: id=20, name=ESP_AES_GCM_C, ivlen=16, keysizemin=160, keysizemax=288

letoams commented
AnatoliChe commented

AES-CTR is not an AEAD, so using null authentication again is not safe.

Yes CTR mode is not secure against CCA and needs AE
Thanks to you I understand it more clearly.

And to AE we can use MAC best chose is HMAC
But using SHA256 or other crypto hash is too expensive.
And I would like to know: using non crypto hash functions in HMAC is secure?
We already use secret key, so collisions wont be a problem.
Let's say SipHash or VMAC,Poly1305-AES or xxHash64.

You should use aes_gcm_c160 on openswan and aes_gcm128 on libreswan ?

Yes, but it's does not work.
I'll try to understand why.