From: Stephan Mueller Subject: Re: [RFC PATCH] crypto: RSA padding transform Date: Sun, 06 Sep 2015 23:17:21 +0200 Message-ID: <2234268.M7UZMy8YJa@tauon.atsec.com> References: <1441494029-6765-1-git-send-email-andrew.zaborowski@intel.com> <35165141.6IIWPIRvUD@myon.chronox.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: tadeusz.struk@intel.com, linux-crypto@vger.kernel.org To: Andrzej Zaborowski Return-path: Received: from mail.eperm.de ([89.247.134.16]:33784 "EHLO mail.eperm.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752753AbbIFVR2 (ORCPT ); Sun, 6 Sep 2015 17:17:28 -0400 In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: 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. How would it prevented that this code does not generate 0x00? Ciao Stephan