Re: Bug 24410 - AES-CBC description

The normative procedure in WebCrypto currently references RFC2898, which
indeed says "the padding string PS consists of 8-(||M|| mod 8) octets each
with value 8-(||M|| mod 8).
"

So this is clearly wrong.

I propose to replace this with a reference to RFC2315.

[The introductory text implies that RFC2898 and RFC2315 specify the same
algorithm and I had just chosen the first when I wrote these procedures,
missing the 8 octet length limitation.]

...Mark




On Thu, Feb 27, 2014 at 10:17 AM, Jim Schaad <ietf@augustcellars.com> wrote:

> I was looking at 2898 which says (in section 6.1)
>
> PBES1 is recommended only for compatibility with existing
>    applications, since it supports only two underlying encryption
>    schemes, each of which has a key size (56 or 64 bits) that may not be
>    large enough for some applications.
>
> However the text in 2315 and 5652 would appear to be the same.   I think
> that the question of which you refer to depends on where you sit.  Most of
> the documents I deal with refer to the CMS set of documents not the PKCS#7
> documents.
>
>
>
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Wednesday, February 26, 2014 1:56 PM
> To: Mark Watson
> Cc: Jim Schaad; public-webcrypto@w3.org
> Subject: Re: Bug 24410 - AES-CBC description
>
> I don't see how RFC 2315, 10.3 p2 is defined as being "64-bit encryption
> blocks", as Jim said.
>
> It's clear it supports blocks up to-and-including 2048-bit
>
> Some content-encryption algorithms assume the
>              input length is a multiple of k octets, where k > 1, and
>              let the application define a method for handling inputs
>              whose lengths are not a multiple of k octets. For such
>              algorithms, the method shall be to pad the input at the
>              trailing end with k - (l mod k) octets all having value k -
>              (l mod k), where l is the length of the input. In other
>              words, the input is padded at the trailing end with one of
>              the following strings:
>
>                       01 -- if l mod k = k-1
>                      02 02 -- if l mod k = k-2
>                                  .
>                                  .
>                                  .
>                    k k ... k k -- if l mod k = 0
>
>              The padding can be removed unambiguously since all input is
>              padded and no padding string is a suffix of another. This
>              padding method is well-defined if and only if k < 256;
>              methods for larger k are an open issue for further study.
>
> RFC 2315 is what all of the crypto libraries reference, so I'm
> hesitant-to-opposed to changing to 5652 for that reason.
>
> On Wed, Feb 26, 2014 at 1:45 PM, Mark Watson <watsonm@netflix.com> wrote:
> Does anyone object to the resolution proposed by Jim ?
>
> ...Mark
>
> On Thu, Feb 20, 2014 at 5:12 PM, Mark Watson <watsonm@netflix.com> wrote:
> I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=24760
>
> On Thu, Feb 20, 2014 at 4:45 PM, Jim Schaad <ietf@augustcellars.com>
> wrote:
> Let's start with a discussion of what reference(s) we should be using for
> the padding algorithm.  The problem with both of the current one is that
> they are setup for 64-bit encryption block algorithms and not the current
> 128-bit block size.  The best reference that I can give you for now would
> be RFC 5652 (Cryptographic Message Syntax) which is the official successor
> to PKCS #7 in any event.  The section that describes the padding algorithm
> is section 6.3
>
> The unpadding algorithm in step 5 of decrypt needs to state "If p is zero
> or greater than 16"
>
>
> Jim
>
>
>
>
>
>