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

[Yong Huang]

On Thu, Feb 29, 2024 at 5:04 PM Daniel P. Berrangé <berrange@redhat.com> wrote:

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

Ok, this is a preferred choice but more work should be done for

the pure software implementation, we may try it in space time.

Thanks for the comments, 

Yong

 

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

--

Best regards