From: Andrzej Zaborowski Subject: Re: [RFC PATCH] crypto: RSA padding transform Date: Mon, 7 Sep 2015 16:42:42 +0200 Message-ID: References: <1441494029-6765-1-git-send-email-andrew.zaborowski@intel.com> <35165141.6IIWPIRvUD@myon.chronox.de> <2234268.M7UZMy8YJa@tauon.atsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Tadeusz Struk , linux-crypto@vger.kernel.org To: Stephan Mueller Return-path: Received: from mail-wi0-f180.google.com ([209.85.212.180]:36655 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751050AbbIGOmo (ORCPT ); Mon, 7 Sep 2015 10:42:44 -0400 Received: by wicgb1 with SMTP id gb1so48195545wic.1 for ; Mon, 07 Sep 2015 07:42:43 -0700 (PDT) In-Reply-To: <2234268.M7UZMy8YJa@tauon.atsec.com> Sender: linux-crypto-owner@vger.kernel.org List-ID: On 6 September 2015 at 23:17, Stephan Mueller wrote: > Am Sonntag, 6. September 2015, 16:33:26 schrieb Andrzej Zaborowski: > > Hi Andrzej, > >>>> + for (pos = 2; pos < child_req->dst_len; pos++) >>>> + if (dst[pos] == 0x00) >>>> + break; >>> >>> What happens if the padding has a 0x00 in its pseudo random data? >> >>The pseudo random bytes must all be non-zero for the padding to be >>unambiguous (RFC3447 iirc). If there's a 0x00 in the first 8 bytes > > I see, I did not know that detail. Now, you use prandom_u32_max to generate > the padding in case of encryption/signing. I do not see any code that filters > out any 0x00 that may be generated by this call. Specifically I use 1 + prandom_u32_max(255) which should give me numbers > 0 although it can't be perfectly uniform. Best regards