RE: AES CFB input parameter "s"

+1
On Feb 24, 2014 8:46 AM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com>
wrote:

>  To me, restricting to CFB8 and naming the algorithm to include the s
> value seems reasonable.
>
>
>
> My sense is that CFB usage in practice is really low. I believe SNMPv3
> uses AES-CFB-128. Other than that, I can’t think of much.
>
>
>
> The only values of s that I’ve seen in practice are s=8 (the smallest
> byte-size value of s) and s=b (which in case of AES means CFB128).
>
>
>
> *From:* Mark Watson [mailto:watsonm@netflix.com]
> *Sent:* Friday, February 14, 2014 5:44 PM
> *To:* Ryan Sleevi
> *Cc:* Vijay Bharadwaj; public-webcrypto@w3.org; Alexey Proskuryakov
> *Subject:* Re: AES CFB input parameter "s"
>
>
>
> Ok, so I guess my question is what should we do in our specification ? At
> least the version we put out for public comment.
>
>
>
> Support only CFB-8, or let the caller choose in the AesCfbParams between
> 8, 64 and 128 ?
>
>
>
> ...Mark
>
> Sent from my iPhone
>
>
> On Feb 14, 2014, at 5:26 PM, Ryan Sleevi <sleevi@google.com> wrote:
>
>  If I were listing priorities of utility for applications and consistency
> of implementation, 8, 128, 64.
>
> I don't see value in arbitrary values of s, nor are there any
> implementations that support it.
>
> On Feb 14, 2014 5:20 PM, "Mark Watson" <watsonm@netflix.com> wrote:
>
>  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
>
>
>
>
>
>