[ANNOUNCE] libkcapi v0.12.0 released

[ANNOUNCE] libkcapi v0.12.0 released

[Stephan Mueller]

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

Re: [ANNOUNCE] libkcapi v0.12.0 released

[Jeffrey Walton]

> 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

Re: [ANNOUNCE] libkcapi v0.12.0 released

[Stephan Mueller]

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

Re: [ANNOUNCE] libkcapi v0.12.0 released

[Jeffrey Walton]

>> > 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

Re: [ANNOUNCE] libkcapi v0.12.0 released

[Stephan Mueller]

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