Re: AES CFB input parameter "s"

You mean support only CFB8 or support only CFB128 ?

...Mark


On Fri, Feb 14, 2014 at 5:17 PM, Ryan Sleevi <sleevi@google.com> wrote:

> I'm inclined to say a over b - outside of 8/128, usage is quite rare.
>
> It was added for the 8 case (GPG, IIRC)
> On Feb 14, 2014 5:07 PM, "Mark Watson" <watsonm@netflix.com> wrote:
>
>> Ok, so the options for our specification are:
>> (a) choose a fixed value e.g. support only CFB128
>> (b) allow the caller to specify the value
>> (c) remove the algorithm from the specification
>>
>> It seems from what you say that it is not the case that everyone supports
>> just one value - so there must be applications for the different values.
>> So, that would suggest we choose (b) if we don't choose (c).
>>
>> ...Mark
>>
>>
>> On Fri, Feb 14, 2014 at 3:16 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>> I haven't heard any implementation movement on CFB.
>>>
>>> If using PKCS#11, only 8-bit, 64-bit, and 128-bit are defined
>>> mechanisms. SP800-38a only provides vectors for 1, 8, 128.
>>>
>>> AFAICT, CNG supports CFB8 and CFB128 with AES. CFB128 isn't until Win8.
>>>
>>> OS X only supports CFB8 from what I can tell (at least, via the
>>> CommonCrypto interface being used to implement in WebKit)
>>> On Feb 14, 2014 3:04 PM, "Mark Watson" <watsonm@netflix.com> wrote:
>>>
>>>> All,
>>>>
>>>> Apologies in advance if this has been discussed before, or has a
>>>> well-known answer.
>>>>
>>>> According to NIST SP800-38A [1] Section 6.3 which we reference for AES
>>>> CFB, the input parameters to the encrypt/decrypt operations consist of an
>>>> IV, the plaintext / ciphertext (respectively) and an additional parameter,
>>>> s, which takes a value between 1 and 128, inclusive.
>>>>
>>>> What values of this shall we support in WebCrypto ?
>>>>
>>>> I assume that if we wish to support more than one value, then we must
>>>> add a property to AesCfbParams for this.
>>>>
>>>> ...Mark
>>>>
>>>> [1] http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
>>>>
>>>
>>

Received on Saturday, 15 February 2014 01:20:55 UTC