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