Re: [PATCH RFC 0/3] Support GM/T 0018-2012 cryptographic standard

["Daniel P. Berrangé" <berrange@redhat.com>]

On Sat, Feb 24, 2024 at 10:34:55PM +0800, Hyman Huang wrote:
> This patchset introduce GM/T 0018-2012 as a crypto backend driver,
> which is applied for block encryption. Currently, we support SM4
> cipher algorithm only.
> 
> GM/T 0018-2012 is a cryptographic standard issued by the State
> Cryptography Administration of China. Visit https://hbba.sacinfo.org.cn
> search GM/T 0018-2012 for brief introduction.
> 
> The objective of the standard is to develop a uniform application
> interface standard for the service-based cryptography device under
> the public key cryptographic infrastructure application framework,
> and to call the cryptography device through this interface to
> provide basic cryptographic services for the uppler layer. For
> more information about contents of the standard, download the
> specificaiton from:
> "https://github.com/guanzhi/GM-Standards/blob/master/GMT密码行标/
> GMT 00018-2012 密码设备应用接口规范.pdf"
> 
> There are two benefits to doing this, at least.
>  * Performance - using a cryptography device for block encryption
>                  offers an opportunity to enhance the input/output
>                  performance once the hardware is certified
>  * Secrecy - hardware manufacturers may fortify cryptography
>              equipment with security features, so increasing the
>              secrecy of block encryption.
> 
> The precise way that vendors implement the standard APIs for data
> encryption using the cryptographic device is uncoupled from the
> GM/T 0018-2012 specification. Thus, if developers enable this
> functionality with the following conditions met, we could accomplish
> the general implementation:
> 
> 1. rename the header file provided by vendor to gmt-0018-2012.h
>    and copy it to the /usr/include directory.
> 2. rename the dynamic library provided by vendor to
>    gmt_0018_2012.so and copy it to the /usr/lib64 or any directory
>    that linker could find before compiling QEMU.
> 3. enable crypto_gmt option when compiling QEMU and make the feature
>    availiable.
> 
> By offering a development package for GM/T 0018-2012, the above
> provisions could be standardized; unfortunately, the hardware
> manufacturer has not completed this task. So developers who don't
> work with the vendor to obtain the cryptography device and related
> library may not be able to test this functionality because the
> standard implementation depends on the cryptography device supplied
> by the hardware vendor. We are hesitant to contribute to this series
> as a result.

Hmm, yes, that is a pretty unpleasant approach.

IMHO there really needs to be a reference implementation that is
pure software. eg a gmt_0018_2012.so + header files that simply
uses an existing crypto library. That way applications can build
and test their support for this, without having to have access
to a specific piece of hardware. Hardware vendors should only
have to provide their library impl, not the headers.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|