Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > Given that this part of the driver only uses synchronous crypto, and > only using a hardcoded algo and mode [pcbc(fcrypt)], of which only a > generic C implementation exists, may I suggest that we switch to a > library based approach instead? > > That way, we can get rid of the crypto API overhead here, and IMO, we > can drop support for this cipher from the crypto API entirely. Ummm... I'm not entirely sure. At some point, I need to look at implementing the rxgk security class to allow gss to be used. That can in theory support any kerberos cipher suite (which don't include pcbc or fcrypt). I don't yet know how much code I could theoretically share with rxkad.c. However, since pcbc and fcrypt are only used by rxkad.c, it might make sense to move them to net/rxrpc/ and hard code them in rxkad.c - though I'd prefer to make an attempt on rxgk first. David
