| Message ID | cover.1708527979.git.yong.huang@smartx.com |
|---|---|
| Headers | show |
| Series | Support GM/T 0018-2012 cryptographic standard | expand |
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
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 :| > >
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. After all, we uploaded this series with the intention of receiving feedback, as the title suggests. We would welcome any suggestions and feedback regarding this feature. Hyman Huang (3): crypto: Introduce GM/T 0018-2012 cryptographic driver meson.build: Support GM/T 0018-2012 cryptographic standard crypto: Allow GM/T 0018-2012 to support SM4 cipher algorithm MAINTAINERS | 3 +- crypto/block-luks.c | 4 +- crypto/cipher-gmt.c | 263 ++++++++++++++++++++++++++++++++++ crypto/cipher.c | 6 +- crypto/cipherpriv.h | 6 + crypto/meson.build | 3 + meson.build | 30 ++++ meson_options.txt | 2 + scripts/meson-buildoptions.sh | 3 + 9 files changed, 315 insertions(+), 5 deletions(-) create mode 100644 crypto/cipher-gmt.c