2

I need to transmit long encrypted messages to a smartcard over a limited capacity link so I need to fragment the messages somewhere before sending thzm.

My problem is that I split the message into 64-byte blocks and then apply a pkcs7 padding. The result is that the padded message always ends with a full block of 16s before encryption. Does this pose a security problem since an attacker will know the last plaintext block ?

One possible solution I might use is splitting into blocks of size 64+x instaed with x random between 0 and 15 so the padding will not be predictable. Is this a good/better idea ?

PS: I use AES-CBC with 128 bit keys

SEJPM
  • 45,967
  • 7
  • 99
  • 205
Romain
  • 145
  • 1
  • 5
  • Off-topic, but since you are on a limited capacity link, and your message has length multiple of 64 bits (where padding is at its most wasteful) doesn't it make more sense to use something like CFB or CTR? – Thomas Feb 26 '13 at 10:03
  • Good remark but the Java smartcard only supports CBC. – Romain Feb 26 '13 at 10:06
  • 2
    If your messages are always a multiple of 16 bytes, you don't need padding at all. – CodesInChaos Feb 26 '13 at 11:51
  • @CodesInChaos In light of the Romain's previous comment, I would expect the smartcard interface to also enforce PKCS7, which does require padding even if the message is a multiple of 16 bytes. – Thomas Feb 26 '13 at 12:05
  • 1
    The smartcard does not implement any padding scheme for AES so I needed to do it myself. And the PDU on the link do not have a fixed length, it is just the maximum I can use. – Romain Feb 26 '13 at 12:38

1 Answers1

6

No, it is not a problem to have the same padding at the end of a message. Some known plaintext is often available in practice (protocol fields, etc). The security of the system is (or at least should be) based entirely on the key.

If you are really worried about it for some reason just change the IV for each 64-byte block. Or as CodesInChaos said in a comment, if messages are always a multiple of 16 bytes, don't even use padding.

mikeazo
  • 38,563
  • 8
  • 112
  • 180
  • 1
    +1 the first paragraph; but I would recommend to use a random IV for each 64-byte block, else we lose IND-CPA security, and more. Also, if there is no integrity check beyond, perhaps, the padding (or if the padding is checked before the integrity check), we might have a setup where some padding oracle attack applies. – fgrieu Feb 26 '13 at 14:11
  • Thank you for your answer, it solves a lot of problems. For integrity and else, I'm using a CBC-MAC with the size prepended (and a different key for encryption and MAC of course). The IV is also different for each message. – Romain Feb 26 '13 at 16:50