[OpenAFS-devel] crypto backend and integration for rxgk

[Troy Benjegerdes]

> >>As such, it seems like we should have the ability for an rxgk-using
> >>tool/utility/etc. to use either hcrypto or libkrb5 for its crypto
> >>backend. This would also leave open the possibility of using an OS
> >>kernel's crypto implementation instead of hcrypto, though that would
> >>require per-OS work and is not needed for an initial implementation.
> >
> >What is the scenario that you are trying to support that makes this
> >necessary and desirable?
> 
> Necessary is debatable.  Desirable, well, all the reasons Debian
> tries hard to eliminate bundled libraries.  The kernel's crypto
> library (or even an openssl krb5 backend) will offer aesni
> acceleration, which hcrypto does not.
> 
> I'm all for the initial implementation being hcrypto-only, but I
> think that it makes sense to leave room for future expansion.

>From a security audit prespective, if you are using an OS that
has widely deployed and audited crypto libs with hardware acceleration,
it would be, well, suicidal from both a performance and security-audit
cost point of view to drag in some new crypto implementation that only
is used by one application, when everything else on the system is using
the hardened stuff that's already there.

For the initial implementation, if you can produce a working hcrypto
fileserver and userspace tools that talk to it, I'll bet 2 bitcoins
that I can get linux-kernel/net/rxgk and a kafs client working before
there is an openafs-kernel module that works with the rxgk fileserver.

If I lose the bet, good, I've got a working rxgk solution.

If I win, we've got two implementations running out of the gate.