Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 13 May 2022 13:29:13 +0100
From:   Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To:     =?utf-8?B?5L2V56OK?= <helei.sig11@bytedance.com>
Cc:     zhenwei pi <pizhenwei@bytedance.com>,
        "S. Tsirkin, Michael" <mst@redhat.com>, arei.gonglei@huawei.com,
        qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
        linux-crypto@vger.kernel.org, jasowang@redhat.com,
        cohuck@redhat.com
Subject: Re: [External] [PATCH v5 5/9] crypto: Implement RSA algorithm by
 hogweed
Message-ID: <Yn5PGWPbP9C4k4wD@redhat.com>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
References: <20220428135943.178254-1-pizhenwei@bytedance.com>
 <20220428135943.178254-6-pizhenwei@bytedance.com>
 <Yn45CxgJ+KNIxXek@redhat.com>
 <90F3B18B-9B7E-423C-A909-45D4527A6B3C@bytedance.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <90F3B18B-9B7E-423C-A909-45D4527A6B3C@bytedance.com>
User-Agent: Mutt/2.2.1 (2022-02-19)
Precedence: bulk

On Fri, May 13, 2022 at 08:26:14PM +0800, 何磊 wrote:
> 
> 
> > On May 13, 2022, at 6:55 PM, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > 
> > On Thu, Apr 28, 2022 at 09:59:39PM +0800, zhenwei pi wrote:
> >> From: Lei He <helei.sig11@bytedance.com>
> >> 
> >> Implement RSA algorithm by hogweed from nettle. Thus QEMU supports
> >> a 'real' RSA backend to handle request from guest side. It's
> >> important to test RSA offload case without OS & hardware requirement.
> >> 
> >> Signed-off-by: lei he <helei.sig11@bytedance.com>
> >> Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
> >> ---
> >> crypto/akcipher-nettle.c.inc | 432 +++++++++++++++++++++++++++++++++++
> >> crypto/akcipher.c            |   4 +
> >> crypto/meson.build           |   4 +
> >> crypto/rsakey-builtin.c.inc  | 209 +++++++++++++++++
> >> crypto/rsakey-nettle.c.inc   | 154 +++++++++++++
> >> crypto/rsakey.c              |  44 ++++
> >> crypto/rsakey.h              |  94 ++++++++
> >> meson.build                  |  11 +
> >> 8 files changed, 952 insertions(+)
> >> create mode 100644 crypto/akcipher-nettle.c.inc
> >> create mode 100644 crypto/rsakey-builtin.c.inc
> >> create mode 100644 crypto/rsakey-nettle.c.inc
> >> create mode 100644 crypto/rsakey.c
> >> create mode 100644 crypto/rsakey.h


> >> +static int qcrypto_nettle_rsa_decrypt(QCryptoAkCipher *akcipher,
> >> +                                      const void *enc, size_t enc_len,
> >> +                                      void *data, size_t data_len,
> >> +                                      Error **errp)
> >> +{
> >> +    QCryptoNettleRSA *rsa = (QCryptoNettleRSA *)akcipher;
> >> +    mpz_t c;
> >> +    int ret = -1;
> >> +    if (enc_len > rsa->priv.size) {
> >> +        error_setg(errp, "Invalid buffer size");
> >> +        return ret;
> >> +    }
> > 
> > Again please report the invalid & expected sizes in the message
> > 
> > We don't need to validate 'data_len' in the decrypt case,
> > as you did in encrypt ?
> 
> In the decrypt case, it is difficult (and unnecessary) to check 'data_len' before 
> we completing the decryption action. If the plaintext buffer is too small, 
> following ‘rsa_decrypt’ will return an error, and it should be valid to pass a very 
> large buffer.
> 
> According to the pkcs#1 stardard, the length of ciphertext should always equal
> to key size, and the length of plaintext can be any value in range [1, key_size - 11]:
> 
> https://datatracker.ietf.org/doc/html/rfc2437#section-7.2

Ok, thanks for explaining.


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