Hi,
The Linux kernel exports a network interface of type AF_ALG to allow user
space to utilize the kernel crypto API. libkcapi uses this network interface
and exports an easy to use API so that a developer does not need to consider
the low-level network interface handling.
The library does not implement any low level cipher algorithms. All consumer
requests are sent to the kernel for processing. Results from the kernel crypto
API are returned to the consumer via the library API.
The kernel interface and therefore this library can be used by unprivileged
processes.
The library code archive also provides a drop-in replacement for the command
line tools of sha*sum, fipscheck/fipshmac and sha512hmac.
The source code and the documentation is available at [1].
[1] http://www.chronox.de/libkcapi.html
Ciao
Stephan
> The Linux kernel exports a network interface of type AF_ALG to allow user
> space to utilize the kernel crypto API. libkcapi uses this network interface
> and exports an easy to use API so that a developer does not need to consider
> the low-level network interface handling.
>
> The library does not implement any low level cipher algorithms. All consumer
> requests are sent to the kernel for processing. Results from the kernel crypto
> API are returned to the consumer via the library API.
>
> The kernel interface and therefore this library can be used by unprivileged
> processes.
>
> The library code archive also provides a drop-in replacement for the command
> line tools of sha*sum, fipscheck/fipshmac and sha512hmac.
>
> The source code and the documentation is available at [1].
That looks awesome Stephan.
How can user code reliably detect when the API is available? Are there
any preprocessor macros to guard code paths in userland? What are the
preprocessor macros we can use to guard it?
Jeff
Am Mittwoch, 26. Oktober 2016, 22:05:28 CEST schrieb Jeffrey Walton:
Hi Jeffrey,
> > The Linux kernel exports a network interface of type AF_ALG to allow user
> > space to utilize the kernel crypto API. libkcapi uses this network
> > interface and exports an easy to use API so that a developer does not
> > need to consider the low-level network interface handling.
> >
> > The library does not implement any low level cipher algorithms. All
> > consumer requests are sent to the kernel for processing. Results from the
> > kernel crypto API are returned to the consumer via the library API.
> >
> > The kernel interface and therefore this library can be used by
> > unprivileged
> > processes.
> >
> > The library code archive also provides a drop-in replacement for the
> > command line tools of sha*sum, fipscheck/fipshmac and sha512hmac.
> >
> > The source code and the documentation is available at [1].
>
> That looks awesome Stephan.
>
> How can user code reliably detect when the API is available? Are there
The detection is done through the various _init calls such as
kcapi_cipher_init. They will return an error if AF_ALG is not available.
According to the documentation these calls return:
* @return 0 upon success; ENOENT - algorithm not available;
* -EOPNOTSUPP - AF_ALG family not available;
* -EINVAL - accept syscall failed
* -ENOMEM - cipher handle cannot be allocated
Technically, the bind operation will fail if the respective AF_ALG interface
is not available.
> any preprocessor macros to guard code paths in userland? What are the
There are no special guards. If AF_ALG is available, all user space processes
can use it.
> preprocessor macros we can use to guard it?
I am not entirely sure I understand the question.
>
> Jeff
Ciao
Stephan
>> > The Linux kernel exports a network interface of type AF_ALG to allow user
>> > space to utilize the kernel crypto API. libkcapi uses this network
>> > interface and exports an easy to use API so that a developer does not
>> > need to consider the low-level network interface handling.
...
>> any preprocessor macros to guard code paths in userland? What are the
>
> There are no special guards. If AF_ALG is available, all user space processes
> can use it.
>
>> preprocessor macros we can use to guard it?
>
> I am not entirely sure I understand the question.
See, for example,
https://github.com/openssl/openssl/blob/master/engines/afalg/e_afalg.c
The versions are kind of arbitrary because there's no easy way to tell
when the gear is available. If I recall from researching things, there
were two components needed for afalg, and they were supposedly
available back to later 2.x kernels.
Things should "just work" for 3.x and 4.x kernels. But if "too early"
a kernel is encountered, then users experience the spectrum from
compile problems to unexplained runtime errors.
Jeff
Am Donnerstag, 27. Oktober 2016, 18:53:45 CEST schrieb Jeffrey Walton:
Hi Jeffrey,
> >> preprocessor macros we can use to guard it?
> >
> > I am not entirely sure I understand the question.
>
> See, for example,
> https://github.com/openssl/openssl/blob/master/engines/afalg/e_afalg.c
>
> The versions are kind of arbitrary because there's no easy way to tell
> when the gear is available. If I recall from researching things, there
> were two components needed for afalg, and they were supposedly
> available back to later 2.x kernels.
>
> Things should "just work" for 3.x and 4.x kernels. But if "too early"
> a kernel is encountered, then users experience the spectrum from
> compile problems to unexplained runtime errors.
I see. There are guards around zerocopy.
AF_ALG appeared with 2.6.38 / 3.0 which already had zerocopy.
I will try a 3.0 kernel with my current lib to see whether it works out of the
box and apply fixes and guards if it does not.
But I am not sure whether I should guard anything for 2.x kernels where we
know that some folks simply backported the AF_ALG interface.
Thanks a lot for the reminder.
Ciao
Stephan