Re: DRBG seeding
Hi Stephan, in my opinion you definitively have to seed the DRBG with true entropy from /dev/random. This is what we are currently doing in userland with the strongSwan DRBG needed for the post-quantum NTRU-based key exchange algorithm. The NIST SP800-90A spec defines a parameter which estimates the entropy contained in the seed, but I think it is extremely difficult to derive an estimate if /dev/urandom is used. Our plans within the strongSwan project is to make the Linux kernel DRBG available via the af-alg interface. Best regards Andreas On 16.04.2015 17:32, Stephan Mueller wrote: Am Donnerstag, 16. April 2015, 23:26:18 schrieb Herbert Xu: Hi Herbert, On Thu, Apr 16, 2015 at 05:07:20PM +0200, Stephan Mueller wrote: I do not see a specific requirement in SP800-90A about the quality of the noise source. Well it explicitly says that you cannot use a DRBG. In the worst case get_random_bytes is completely deterministic. That said, I already developed an in-kernel version of /dev/random. I sent the patch to LKML some half year ago. If I understood Ted Tso right, there is no general objection against adding that in-kernel interface. See [1] for the thread. Furthermore, I already started working on updating the DRBG to use that in- kernel /dev/random interface. Shall I pursue that work in earnest now? [1] https://lkml.org/lkml/2014/5/11/276 Yes I think we should do this. Ok, I will work on that after I added the global lock to the DRBG. Thanks, Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source 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
Re: IPSec hmac(sha256) truncation bits length
Hi Nicolae, up to the Linux 2.6.32 kernel the SHA256 hash was erroneously truncated to 96 bits. With Linux 2.6.33 the correct truncation to 128 bits was introduce as well as the SHA384_192 and SHA512_256 data integrity algorithms. If you want to apply the correct SHA2 truncation, use XFRMA_ALG_AUTH_TRUNC instead of XFRMA_ALG_AUTH. Best regards Andreas On 03/04/2015 06:13 PM, Nicolae Rosia wrote: Hello, I'm trying to understand why icv_truncbits is set to 96 for hmac(sha256) in xfrm_algo.c because RFC4868 [1] says that the truncation length for HMAC-SHA256 should be 128. Am I looking in the wrong place? [1] https://tools.ietf.org/html/rfc4868#section-2.6 Best regards, Nicolae Rosia -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Open Source 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
Linux 2.6.28 and AEAD initialization
crypto_aead *aead; int err; aead = crypto_alloc_aead(x-aead-alg_name, 0, 0); err = PTR_ERR(aead); if (IS_ERR(aead)) goto error; error: return err; } - crypto/aead.c:crypto_alloc_aead() { alg = crypto_lookup_aead(alg_name, type, mask); if (IS_ERR(alg)) { err = PTR_ERR(alg); goto err; } err: if (err != -EAGAIN) break; if (signal_pending(current)) { err = -EINTR; break; } } return ERR_PTR(err); } - crypto/aead.c:crypto_lookup_aead() { struct crypto_alg *alg; alg = crypto_alg_mod_lookup(name, type, mask); if (IS_ERR(alg)) return alg; /* after the first call alg-cra_type is crypto_nivaead_type */ if (alg-cra_type == crypto_aead_type) return alg; if (!alg-cra_aead.ivsize) return alg; return ERR_PTR(crypto_nivaead_default(alg, type, mask)); } - crypto/aead.c:crypto_nivaead_default() { if ((err = crypto_register_instance(tmpl, inst))) { tmpl-free(inst); goto put_tmpl; } /* Redo the lookup to use the instance we just registered. */ err = -EAGAIN; put_tmpl: crypto_tmpl_put(tmpl); kill_larval: crypto_larval_kill(larval); drop_larval: crypto_mod_put(larval); out: crypto_mod_put(alg); return err; } - crypto/algapi.c:crypto_register_instance() { larval = __crypto_register_alg(inst-alg); if (IS_ERR(larval)) goto unlock; hlist_add_head(inst-list, tmpl-instances); inst-tmpl = tmpl; unlock: up_write(crypto_alg_sem); err = PTR_ERR(larval); if (IS_ERR(larval)) goto err; crypto_wait_for_test(larval); err = 0; err: return err; } - crypto/algapi.c:__crypto_register_alg() { ret = -EEXIST; ... if (crypto_is_larval(q)) { if (!strcmp(alg-cra_driver_name, q-cra_driver_name)) goto err; continue; } } Uff! == 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]== -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html