Hi Tobias, yes I would strongly advocate a specific proposal for Android clients using libipsec, restricted to AES combined with SHA1/SHA2.
And we should definitively add HMAC_SHA2_256_128 to our default ESP proposal, putting it in front of AES_XCBC_96 and HMAC_MD5_96. Andreas On 27.09.2012 09:34, Tobias Brunner wrote: > Hi Andreas, > >> in fact, very strange collection of cipher suites the >> strongSwan Android client is proposing: >> >> received proposals: ESP: >> AES_CBC_128/AES_CBC_192/AES_CBC_256/ >> 3DES_CBC/BLOWFISH_CBC_256/ >> HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/ >> NO_EXT_SEQ >> >> I'm not aware that libipsec would support blowfish_cbc, 3des_cbc, >> aes_xcbc, and hmac_md5_96 and sha256_128,sha384_192 and sha512_256 >> are prominently missing. Tobias could you check that? > > That's just charon's default ESP proposal (see proposal.c). Because > charon currently doesn't know which algorithms the IPsec stack actually > supports this is static (unlike the dynamically constructed default IKE > proposal). With kernel-pfkey we could theoretically query the kernel > for its supported algorithms, libipsec would obviously support it too > but kernel-netlink has no interface to do so. But I suppose we could > construct a custom proposal for the Android app with the knowledge of > what libipsec actually supports (which currently is AES + SHA1/SHA2). > > Regards, > Tobias ====================================================================== Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]==
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
