Re: theoretical rpcsec_gss deadlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Mar 14, 2008 at 02:23:20PM -0400, Kevin Coffman wrote:
>
> Herbert, Bruce Fields says you suggested a while back that an
> interface was already there, or was being planned?  Can you give me
> any details?  Could we possibly help?

Have a look at the linux-crypto archive for the async hash patch
that was posted in January/February.  That will eventually allow
the same tfm to be used in parallel.  However, there is much work
to be done as all existing transforms would have to be updated for
this.

> Another question:  The current checksum code deals only with "md5".
> Support for newer Kerberos encryption types uses keyed hashes.  In an
> extreme case, support for the rc4-hmac Kerberos encryption type
> requires a new hash key be derived for each rpc.  Would this interface
> be able to deal with changing keys as well?  In that same case, the
> "rc4" cipher key changes with each rpc as well.

Sorry, but setting the key is an expensive operation in general,
so the rule is one tfm per key to allow simultaneous operations
on the same key.

However, if hmac is the only mode you're ever going to support,
you could consider implementing hmac by hand which would allow you
to share the underlying algorithm tfm object.  This is because
the hmac key just gets hashed into the underlying tfm.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux