[Bug 25659] New: AES-CBC mode does not describe concretely how padding is added

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25659

            Bug ID: 25659
           Summary: AES-CBC mode does not describe concretely how padding
                    is added
           Product: Web Cryptography
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Web Cryptography API Document
          Assignee: sleevi@google.com
          Reporter: sleevi@google.com
                CC: public-webcrypto@w3.org

The definition of AES-CBC mode defines a variable, "padded-plaintext", that is
the result of "adding padding octets to ciphertext"

However, ciphertext is an ArrayBuffer/ArrayBufferView, and thus the length of
the underlying buffer is fixed.

While possible to specify that an implementation must create a copy of
ciphertext that is aligned to blocksize, and THEN add the padding octets, a
better definition would provide more prosaic guidance and flexibility to
implementors.

For example, if the underlying implementation supported streaming operations, a
conforming user agent might only have to create a copy of the final block of
"ciphertext". Likewise, if the underlying implementation supports adding the
padding itself for unaligned inputs, the specification should permit conforming
user agents to not having to modify the data.

That is, rather than normatively specifying that "paddedPlaintext" is equal to
the result of the UA adding padding, the inputs should be specified "as if"
plaintext was padded according to the padding rules, thus allowing flexibility
and avoiding confusion about whether or not it's necessary to invoke the
ArrayBuffer constructor during the asynchronous processing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 12 May 2014 05:20:31 UTC