- From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
- Date: Mon, 24 Feb 2014 16:46:39 +0000
- To: Mark Watson <watsonm@netflix.com>, Ryan Sleevi <sleevi@google.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Alexey Proskuryakov <ap@webkit.org>
- Message-ID: <99eb36a89898442d9dc0747daa007839@DFM-CO1MBX15-08.exchange.corp.microsoft.com>
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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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 Monday, 24 February 2014 16:47:14 UTC