Re: Using AES-CBC decrypt without padding

On Tue, Jun 24, 2014 at 4:25 AM, Stefan Ortner <Stefan.Ortner@sophos.com>
wrote:

>  Hi Ryan,
>
>
>
> I agree manually handling the padding may not be a good idea, I was just
> trying to find a way to solve my issue.
>
>
>
> So, I was playing around with the implementation in Chrom{e/ium} and
> noticed the following:
>
> I was trying to decrypt a file encrypted with one of our encryption
> products, which does encrypt a file in 512 byte chunks with an IV that can
> be calculated for each chunk (for random accessing encrypted files, without
> decrypting the whole file). However, I failed decrypting, since after the
> first chunk I received an OperationError (which should be a DataError?).
> Only then I spotted that in the Specification the decryption process checks
> for a valid padding, and therefore only allows decryption
>
Indeed, Chromium is not spec compliant in this regard.
Will follow up on https://code.google.com/p/chromium/issues/detail?id=388352
Thanks.


> of data that has a padding.
>
> The padding scheme applied always adds data, even if the plain data is
> already a multiple of AES block length, which results in an encrypted data
> length of x + 1 block length. Our encrypted chunk do not have this extra
> block with padding information.
>
>
>
> Basically what I need is a way to decrypt data that does not have that
> extra block of padding information.
>
>
>
> I hope this helps.
>
> Regards,
>
> Stefan
>
>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Monday, June 23, 2014 9:52 PM
> *To:* Stefan Ortner
> *Cc:* public-webcrypto-comments@w3.org
> *Subject:* Re: Using AES-CBC decrypt without padding
>
>
>
>
>
>
>
> On Fri, Jun 20, 2014 at 10:50 PM, Stefan Ortner <Stefan.Ortner@sophos.com>
> wrote:
>
> There should be an option in AES-CBC to allow decryption without enforcing
> the padding scheme used in encrypt().
>
> It is quite common when encrypting larger files to portion it into smaller
> chunks that are a multiple of AES block length, and saving all the padding
> blocks can produce quite some overhead and is therefore discarded.
>
>  Since AES-CBC is quite popular, there is already a lot of encrypted data
> out there that can simply not be decrypted when using WebCrypto API,
> because of the missing padding, or “wrong” padding in the data. So by
> allowing decryption without enforcing the padding, programmers can manually
> handle the padding themselves, if it differs from the padding used
> WebCrypto AES-CBC encrypt().
>
>
>
> Regards,
>
> Stefan
>
>
>  ------------------------------
>
>
> Sophos GmbH, Leonfeldnerstraẞe 2, 4040 Linz, Österreich
> Firmenbuchnummer: FN 387465 b, Ust.-ID Nr. ATU 65950312 Sitz: Wiesbaden,
> Deutschland
> Firmenbuchgericht: Wiesbaden, Deutschland
>
>
>
> Stefan,
>
>
>
> I'm not quite sure I follow your request, so I'd have to ask for more
> information.
>
>
>
> Can you provide an example of a system that actually implements what
> you've described, so we can discuss whether or not it's actually possible
> today, without any changes to the API, as I believe it is?
>
>
>
> I strongly disagree that allowing 'programmers to manually handle the
> padding themselves' is a good idea; one of the motivating concerns for the
> development of Web Crypto is the subtlety involved with
> timing-relevant/secret-dependent operations. This includes padding checks
> (as we've seen with things like Lucky 13), and so the goal has been to
> isolate, as much as possible of that, from being something in scope for
> programmers using this API.
>
>
>
> However, I think you can accomplish this today, and if you're able to
> provide more details - including a bit more of description about why you
> don't believe it's possible today - then we should be able to have a more
> fruitful discussion.
>
>
>
> Cheers!
>
> ------------------------------
>
> Sophos GmbH, Leonfeldnerstraẞe 2, 4040 Linz, Österreich
> Firmenbuchnummer: FN 387465 b, Ust.-ID Nr. ATU 65950312 Sitz: Wiesbaden,
> Deutschland
> Firmenbuchgericht: Wiesbaden, Deutschland
>
>