Re: Using AES-CBC decrypt without padding

On Tue, Jun 24, 2014 at 7: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 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.
>
It seems like you could patch your implementation to fix this, though.  You
know the key and the data length, so you could generate the the proper
encrypted padding block.  Likewise, in the encrypt direction, you could
trim the extra padding block.  This is a hack, but it does show that this
is not a fundamental limitation of the API, just a choice of default.  And
as people here know, I am a fan of safe defaults.

BTW, if you've got a chance to try it in Firefox (Nightly/Aurora), I would
be interested to know the results.

--Richard




>
>
> 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
>
>