RE: Using AES-CBC decrypt without padding

I guess you are right, I can compute the missing padding block by using the last encryption block as IV for a full padding block and then discard the additional padding block added by the API. This indeed looks like a bad hack, but I’ll try it anyway.

I’ll give it a try on Firefox later this week, I’ll keep you posted.

Regards Stefan


From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Monday, June 30, 2014 8:44 PM
To: Stefan Ortner
Cc: Ryan Sleevi; public-webcrypto-comments@w3.org
Subject: Re: Using AES-CBC decrypt without padding



On Tue, Jun 24, 2014 at 7:25 AM, Stefan Ortner <Stefan.Ortner@sophos.com<mailto: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<mailto:sleevi@google.com>]
Sent: Monday, June 23, 2014 9:52 PM
To: Stefan Ortner
Cc: public-webcrypto-comments@w3.org<mailto: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<mailto: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


________________________________

Sophos GmbH, Leonfeldnerstraẞe 2, 4040 Linz, Österreich
Firmenbuchnummer: FN 387465 b, Ust.-ID Nr. ATU 65950312 Sitz: Wiesbaden, Deutschland
Firmenbuchgericht: Wiesbaden, Deutschland