5

I'm playing around with an application for secure email-like communication and I want to perform length hiding padding on the plaintext messages so they always have a consistent size before encrypting with AES.

I would like to do PKCS7 style padding (if possible), because it's easy to figure out how much to strip from the decrypted output, but how would you do such a padding if the amount of padding exceeds what can be described with one byte? i.e. if I have a message that is 2.000 bytes in size and I want to pad it to become 16.000 bytes in size. This requires a padding size of 14.000 bytes which is 0x36B0 in hex, how would the padding look like for such a value and how can I know that I should take the last two bytes instead of the last byte to find the padding size?

Thanks in advance!

SEJPM
  • 45,967
  • 7
  • 99
  • 205
Keke Alho
  • 51
  • 2
  • 1
    I strongly encourage you not to invent your own cryptosystem. You will be a victim of Schneier's law. If you think you'll be safe by sticking with an AES core and writing glue code, you're gonna have a bad time. – Stephen Touset Jun 21 '13 at 20:45
  • Don't worry, I'm not inventing my own crypto at all, I just want to hide the length of the actual plaintext payload so that if "Mallory" gets access to an encrypted message, she can't tell the difference between a short message and a long message. All ciphertext will have the same length, regardless of the length of the actual plaintext payload. The plaintext could be "Hello World!" or it could be a super long important message. She has no way of telling from the ciphertext. – Keke Alho Jun 21 '13 at 20:54
  • "Inventing your own crypto" isn't simply limited to coming up with new ciphers. It very much includes implementing your own cryptographic schemes, which this absolutely is. Do not fool yourself into thinking otherwise. "I just want to hide the..." is a smoking gun here. – Stephen Touset Jun 21 '13 at 21:02
  • So is there any Schneier-Approved™ way of doing length hiding padding or is it something people don't care about? – Keke Alho Jun 21 '13 at 21:12
  • I don't believe there are any widely-used, heavily-analysed solutions to the problem. However, there's at least one published paper on the topic that may prove helpful. They also have an associated set of presentation slides. – Stephen Touset Jun 21 '13 at 21:28
  • 1
    To the other part of your question, it's generally not something I've ever seen people care about. Part of that is because it can be impractical — unless you use an extreme amount of extra padding, I will still be able to tell if your message contained (for instance) HD video versus something like an image or PDF, or only textual data. – Stephen Touset Jun 21 '13 at 22:53
  • 1
    @StephenTouset If you apply say 2% padding, that's usually enough to hide which video you encrypted and not just that you encrypted some video. So even if you only apply a moderate amount of padding the gain is pretty big. The current version of Tahoe-LAFS doesn't apply padding, which I consider a pretty big flaw. – CodesInChaos Jun 23 '13 at 08:35
  • 1
    @StephenTouset, I don't think it's quite that bad. And we don't know his situation. There are many considerations: who are the attackers? What are the consequences if they learn the message length? Is it just message length, or does time of transmission reveal sensitive information? What about number of messages? Who the messages are sent to? I think the OP needs to examine all aspects of traffic analysis, figure out what's important to his security situation, then implement it. It may be more than padding he needs, but it's still not "roll-your-own-algorithm" bad. – John Deters Jun 24 '13 at 14:06
  • Compose all your messages in haiku form so they're all the same length. As a side effect, you'll learn to find which parts of the message are unimportant and cut them. – Zsbán Ambrus Jun 24 '13 at 14:32

2 Answers2

6

As you note, PKCS7 padding isn't designed to do exactly what you want; it's really designed to allow you to pad up to the next multiple of the block size, that is, to the next multiple of 8 or 16. That it does rather well; however, it's not designed to do what you want with it.

I would note that for block ciphers, as long as you also include a good Message Authentication Code or some other way of ensuring integrity, that the actual padding method isn't critical to security; the AES encryption itself will ensure that there is no information leakage other than message length, and the MAC will ensure that, if the attacker tries to play games with modifying the message, well, that'll always result in a MAC failure, and so that attacker won't learn anything). This is true even if you try to design a padding scheme specifically to leak information (assuming, of course, that your padding method doesn't use the key).

Hence, the only real constraints on your padding scheme is:

  • Not to leak any information do to the message length (that's the one thing AES does not disguise)

  • Be able to remove the padding to obtain the original message without ambiguity

As long as you follow those two constraints, you're golden. One obvious way to meet both goals is to pad the message out to a fixed length; and then add a 2 (or 4) byte 'original message length' at either the beginning or the end of the message.

I'm assuming that you aren't concerned about interoperability with existing systems; if you are, then you'll need to live within whatever system they are using.

And, the above answer "the padding method is not critical" applies only to block ciphers along with some MAC); when you consider other cryptographical primitives (say, RSA), the padding method does become important in those cases.

poncho
  • 147,019
  • 11
  • 229
  • 360
  • 1
    This presumes that OP can and will implement encrypt-then-MAC correctly, not accidentally leak lengths through timing information (used strlen? oops.), and one of a zillion other ways to get it wrong. – Stephen Touset Jun 21 '13 at 20:51
  • Although I suppose OP could pad the message manually, and then feed it through an existing, standardized encryption mode (e.g., AES in GCM mode) that itself implements padding. – Stephen Touset Jun 21 '13 at 20:52
  • Another option could be to send two cryptograms for each message. The first would contain the length of the message, and the second would be the encrypted message with an arbitrary amount of truly random data padded onto the end. – Stephen Touset Jun 21 '13 at 22:50
  • 3
    @StephenTouset For email like systems timing isn't that big a concern, but if you care about timing I'd worry more about higher level systems working on the plaintext rather than about the padding stripping code. Since this padding is protected by the MAC a timing difference doesn't allow forgery or anything really bad beyond losing a bit of length hiding. – CodesInChaos Jun 22 '13 at 08:17
  • 1
    Right, my concern was that a fault implementation of a homemade padding scheme could easily negate the entire benefit it's supposed to provide. – Stephen Touset Jun 23 '13 at 04:44
  • poncho, I would really want to +1 this except for the statement that "that the actual padding method isn't critical to security". For block cipher modes the padding mode should never be critical to security. This is different from padding modes defined for e.g. RSA. An authentication tag is the only way to provide security, padding oracle attacks makes block cipher padding only a benefit a possible attacker. – Maarten Bodewes Jun 24 '13 at 11:18
  • @owlstead: you are quite correct; the question was in the context of a block cipher, and hence I answered within that context. Of course, once you get into other things (such as RSA), the answer changes. I should have been more explicit within my answer; I just edited the answer to include those caveats. – poncho Jun 24 '13 at 12:36
  • Deleted my last comment and +1, as long as nobody thinks of using block cipher mode padding for ensuring integrity, with or without MAC... – Maarten Bodewes Jun 24 '13 at 18:32
0

As both you and the other answer note, PKCS#7 padding specifically is only designed to fill out cipher blocksizes.

What you're looking for is bulk junk data to disguise the message size by rounding it up to an anonymity class. The best way (in my estimation) to implement that would be, if your application-layer supports headers of any kind that are inserted inside the encryption, "alongside" the message and undifferentiated from it to an eavesdropper, to leverage such a header to pad-out the message to predetermined lengths. The padding data SHOULD be uniformly random.

(If your system compresses messages before encryption for additional security, you may want to ensure that your bulk padding data is excluded from this compression: both to avoid wasting CPU cycles banging a compression algorithm against uniformly random data, and to make it far easier to target exact ciphertext lengths.)

If your message doesn't currently include header support, you may want to insert an additional thin protocol layer; encapsulate the message in some container that provisions for a "junk" attachment — which would, again, be applied "inside" (logically before) signing and encryption.

JamesTheAwesomeDude
  • 930
  • 5
  • 22