netdev - [PATCH 0/4] crypto: CRYPTO_MAX_ALG

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 6 Apr 2017 16:15:09 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Alexander Sverdlin <alexander.sverdlin@...ia.com>
Cc:     "David S. Miller" <davem@...emloft.net>,
        linux-crypto@...r.kernel.org, netdev@...r.kernel.org
Subject: [PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

On Thu, Mar 16, 2017 at 03:16:29PM +0100, Alexander Sverdlin wrote:
>
> This is a regression caused by 856e3f4092
> ("crypto: seqiv - Add support for new AEAD interface")
> 
> As I've said above, I can offer one of the two solutions, which patch should I send?
> Or do you see any better alternatives?

Here is a series of patches which should fix the problem.

The first three patches prepare the user-space interfaces to deal
with longer names.  The final patch extends it.

Note that with crypto_user I haven't actually extended it to
configure longer names.  It'll only be able to configure names
less than 64 bytes.  However, it should be able to dump/read
algorithms with longer names, albeit the name will be truncated
to 64 bytes length.

Steffen, when convenient could you look into extending the crypto
user interface to handle longer names (preferably arbitraty length
since netlink should be able to deal with that)?

Likewise xfrm is still fixed to 64 bytes long.  But this should
be OK as the problematic case only arises with IV generators for
now and we do not allow IV generators to be specified through xfrm.

af_alg on the other hand now allows arbitrarily long names.

As the final patch depends on all three it would be easiest if
we pushed the xfrm patch through the crypto tree.  Steffen/David?

Thanks,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt