1
$\begingroup$

Imagine a protocol where all one time pad messages are of a fixed length. And they're textual only, à la Truths/Tweets. So a short message would be padded with spaces (ASCII 32) up to the protocol's fixed length, and then transmitted. It would also be appended with a properly formed RFC 2104 HMAC which itself is encrypted with more one time pad material.

Is it necessary to incorporate the length of the original plain text somewhere within the protocol?


I sense that this is a duplicate of Is the HMAC construction really neccessary for a fixed length message?, but that question has two long answers that I'm struggling to parse. A simplification of those or an answer to this would be appreciated.

$\endgroup$
3
  • 1
    $\begingroup$ If the message itself can contain spaces, then the padding you suggest is in general not reversible unless you know the original length. However, that can be fixed with a proper padding scheme. $\endgroup$
    – Maeher
    Jun 5, 2022 at 11:07
  • $\begingroup$ @Maeher ends with spaces. You can perfectly unpad as long as the last part of the message doesn't consists of something that can be confused with the padding. $\endgroup$
    – Maarten Bodewes
    Jun 5, 2022 at 13:39
  • 1
    $\begingroup$ I'll note that tweets fixed maximum length is calculated in UTF-8 lengthsof unicode Grapheme Clusters, not in bytes. For padding, we care about bytes. $\endgroup$ Jun 5, 2022 at 14:13

1 Answer 1

2
$\begingroup$

Is it necessary to incorporate the length of the original plain text somewhere within the protocol?

No, as long as the final part of the message cannot be confused with the padding used, it would be possible to deterministically unpad the message. In your case, if your message cannot end with spaces then you can strip the spaces off. However, if it did anyway then the final spaces are obviously.

I sense that this is a duplicate of Is the HMAC construction really neccessary for a fixed length message?

No, that's a different question. The reason is that it talks about the HMAC itself being necessary, rather than the padding.

HMAC is build using a hash function, which is already padded internally, presuming that it has a particular block size for the message input. For SHA-2 that means that the message is padded using bit padding leaving some bytes to indicate the message size in bits.

HMAC itself already has a length indicator within the hash. But even without it: adding any data to the message would immediately change the authentication tag, so it is impossible for an adversary to add data without notice. Just to be on the safe side I would also include the padding into the hash calculation, if just to disallow length information leaking from the unpadding. But in the end, for the security of the HMAC, the padding of the plaintext message is not required; it already does that internally.

I'd make the padding / unpadding separate from any cryptographic algorithms, as you only want to validate the padding after the HMAC verification has taken place. Even then you should really take care of any operations not to leak information on the message size through side channels.


What you do seem to be talking about is padding required to hide the message size. That is different from padding for e.g. block ciphers or hash functions. The issue is here that a padding scheme must properly allow for input messages of any size. This may also mean that the padding may be more than the 255 bytes that e.g. PKCS#7 compatible padding allows for.

In that sense, it might be a good idea to include a length in case the padding is larger than 8 bytes. In that case you could set a single bit and assume the other 63 bits consist of the message or padding length. In other words: a length indicator could be more efficient than some padding scheme. OTOH, bit padding would work fine as well, with the slight disadvantage that you may need to look at all the padding bytes to find the first one that is not set to all zero / 0x80.

$\endgroup$
3
  • $\begingroup$ Yes, I'm targeting at least 10x Tweet length, or 2816 byes (44x a Sha512 output). $\endgroup$
    – Paul Uszak
    Jun 5, 2022 at 23:49
  • $\begingroup$ Alright, I hope you find the answer useful. Not sure if you wanted to tweak the SHA-512 itself, but I assumed that that was not the case in my answer. If anything is missing let me know. $\endgroup$
    – Maarten Bodewes
    Jun 6, 2022 at 13:10
  • 1
    $\begingroup$ Yes, very much so. I was just waiting before accepting as to not discourage anyone else from answering (it's only been a day)... $\endgroup$
    – Paul Uszak
    Jun 7, 2022 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.