Message padding

[ncri]

Does it make sense to pad messages so that the encrypted message cannot be guessed by length? Or is otr taking care of this?

[arlolra]

The spec says,

Encrypted message (DATA)
Using the appropriate encryption key (see below) derived from the sender's and recipient's DH public keys (with the keyids given in this message), perform AES128 counter-mode (CTR) encryption of the message. The initial counter is a 16-byte value whose first 8 bytes are the above "top half of counter init" value, and whose last 8 bytes are all 0x00. Note that counter mode does not change the length of the message, so no message padding needs to be done. If you want to do message padding (to disguise the length of your message), use the above TLV of type 0.

And,

Type 0: Padding
The value may be an arbitrary amount of data, which should be ignored. This type can be used to disguise the length of the plaintext message.

I suppose we could expose an API to optionally include application specific padding. Is that something you're interested in?

[ncri]

Yes, sounds good! So the app then has to take care of specifying the padding amount that is needed for making all messages have the same length I assume? This will only work in case the encryption is fixed length. Is it? In that case it would be useful to be able to simply specify an upper limit for message length. Messages shorter that that limit could then be automatically padded. Longer ones truncated, so the app only has to take care not to send too long messages. Does that make sense? I'm not very familiar with the OTR specs.