Re: DRBG seeding

2015-04-16 Thread Andreas Steffen 

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

2015-03-04 Thread Andreas Steffen 
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

2009-01-20 Thread Andreas Steffen 
 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