[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.OSX.2.20.1605120933350.23376@mjmartin-mac01.local>
Date: Thu, 12 May 2016 10:01:05 -0700 (PDT)
From: Mat Martineau <mathew.j.martineau@...ux.intel.com>
To: David Howells <dhowells@...hat.com>
cc: Mat Martineau <mathew.j.martineau@...ux.intel.com>,
tadeusz.struk@...el.com, linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org, keyrings@...r.kernel.org,
linux-crypto@...r.kernel.org, dwmw2@...radead.org
Subject: Re: [RFC PATCH 5/8] KEYS: Provide software public key query function
[ver 3]
On Thu, 12 May 2016, David Howells wrote:
> Mat Martineau <mathew.j.martineau@...ux.intel.com> wrote:
>
>>> + len = crypto_akcipher_maxsize(tfm);
>>> + info->key_size = len * 8;
>>> + info->max_data_size = len;
>>> + info->max_sig_size = len;
>>> + info->max_enc_size = len;
>>> + info->max_dec_size = len;
>>
>> If len > UINT16_MAX, should UINT16_MAX be reported as the max size? Similar
>> question for len*8 and key_size.
>
> key_size is 32 bits, but the other sizes are all 16 bits, so you would need a
> 524288-bit key to exceed their capacity. I'm not sure that's likely anytime
> soon, but should I just make all the sizes 32-bit anyway?
Given that cryto_akcipher_maxsize() returns an int and keyctl_pkey_query
is part of the userspace API, I support bumping the sizes to 32-bit.
--
Mat Martineau
Intel OTC
Powered by blists - more mailing lists