linux-kernel - Re: authenc methods vs FIPS in light of unencrypted associated data

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160603101205.GA31461@gondor.apana.org.au>
Date:	Fri, 3 Jun 2016 18:12:05 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	Stephan Mueller <smueller@...onox.de>
Cc:	Marcus Meissner <meissner@...e.de>, davem@...emloft.net,
	linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: authenc methods vs FIPS in light of unencrypted associated data

On Fri, Jun 03, 2016 at 08:42:31AM +0200, Stephan Mueller wrote:
>
> Herbert, when using crypto_spawn_*, is there a flag set by the crypto API that 
> the to-be-instantiated cipher is invoked by the kernel crypto API instead of 
> by a user? I would assume that the INTERNAL flag could be of relevance here. 
> If that INTERNAL flag is set, I think that the function alg_test could be 
> changed such that if the INTERNAL flag is set, the fips_allowed flag is not 
> enforced.

Yes we can certainly set INTERNAL for this case.

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