On Thu, Jun 04, 2020 at 10:09:10PM -0700, Eric Biggers wrote:
>
> There's also a case where "seqiv" is used without counter mode:
>
> net/xfrm/xfrm_algo.c:
>
> {
> .name = "rfc7539esp(chacha20,poly1305)",
So
select CRYPTO_SEQIV if CRYPTO_CTR || CRYPTO_CHACHA20POLY1305
and if the list gets too long we could create another symbol that is
selected by the algorithms, say CRYPTO_SEQIV_ESP which could then
be used as the condition:
config CRYPTO_SEQIV_ESP
bool
config CRYPTO_CTR
select CRYPTO_SEQIV_ESP
config INET_ESP
select CRYPTO_SEQIV if CRYPTO_SEQIV_ESP
> FWIW, we make CONFIG_FS_ENCRYPTION select only the algorithms that we consider
> the "default", and any "non-default" algorithms need to be explicitly enabled.
>
> Is something similar going on here with INET_ESP and INET_ESP6? Should "seqiv"
> be considered a "default" for IPsec?
The default with IPsec is up to the user-space IPsec manager,
e.g., libreswan. So the kernel has no idea what the default
is. Also, unlike filesystems IPsec is about interoperability
so the default is actually a list of algorithms.
If you were using libreswan then top of the list is gcm(aes),
followed by aes(cbc)+sha256, and then aes(cbc)+sha1.
Incidentally we should probably prune the INET_ESP select list.
At least MD5/SHA1/DES shouldn't be on it. We probably should
add AES, SHA256 and GCM to the list.
Another potential improvement is to merge the two select lists
between ESP and ESP6. Perhaps move them to a new tristate say
XFRM_ESP that would then be selected by ESP and ESP6.
Cheers,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
