On Fri, 11 Aug 2017, Andrew Zaborowski wrote:
HI,
On 11 August 2017 at 02:48, Mat Martineau
<mathew.j.martineau@xxxxxxxxxxxxxxx> wrote:
The last round of reviews for AF_ALG akcipher left off at an impasse around
a year ago: the consensus was that hardware key support was needed, but that
requirement was in conflict with the "always have a software fallback" rule
for the crypto subsystem. For example, a private key securely generated by
and stored in a TPM could not be copied out for use by a software algorithm.
Has anything come about to resolve this impasse?
There were some patches around to add keyring support by associating a key
ID with an akcipher socket, but that approach ran in to a mismatch between
the proposed keyring API for the verify operation and the semantics of
AF_ALG verify.
AF_ALG is best suited for crypto use cases where a socket is set up once and
there are lots of reads and writes to justify the setup cost. With
asymmetric crypto, the setup cost is high when you might only use the socket
for a brief time to do one verify or encrypt operation.
Would that time be shorter when going through the keyctl API?
There's a certain amount of work to be done for a one-off crypto operation
no matter what the API is: load a key, set up the operation, provide the
input, read the output, and clean up. keyctl() handles that "one-off" case
with a smaller sequence of system calls, but is not as good for streaming.
In any case there will be situations, similar to the lightweight TLS
implementation use case, where this isn't a factor.
Given the efficiency and hardware key issues, AF_ALG seems to be mismatched
with asymmetric crypto.
The hardware key support would obviously be a benefit but it's
orthogonal to this I believe. That issue is not specific to akcipher
either, there will be hardware-only symmetric keys that can't be used
with current ALG_IF.
The ALG_IF API provides a slightly lower level access to the
algorithms listed in /proc/crypto than the keyctl API and I don't see
the reason that some of those algorithms should not be available.
I also would like to have more of those algorithms exposed to userspace,
and I'd like to make sure the API is a good fit. There was extensive
discussion of AF_ALG akcipher last year. v8 of the patch set updates the
implementation but doesn't address the API concerns that kept the previous
versions from being merged, so we seem to be at just as much of an impasse
as before.
--
Mat Martineau
Intel OTC
