RE: Bug 24410 - AES-CBC description

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

Received on Thursday, 27 February 2014 18:19:41 UTC