Understanding the computation of additional MAC block counts in `TlsMac.java`
Dear Bouncy Castle Developers,
I am trying to understand the calculation of `int extra` in method
`calculateMacConstantTime` in `org/bouncycastle/crypto/tls/TlsMac.java`
in Bouncy Castle 1.57 (I have downloaded the source as
`lcrypto-jdk15on-157.tar.gz` with SHA-256
From my intuitive understanding it does the following:
It calculates a `DigestBlockCount` for the plaintext length (including
padding) and subtracts from it the `DigestBlockCount` of the actual
message's length resulting in a number of blocks to additionally
process in order to obfuscate the actual number of blocks input
into the HMAC (which is required to avoid timing attacks).
Let's assume the hash algorithm in use is SHA-1 and the TLS version is
1.0. In this case `getDigestBlockCount` adds a ``digest overhead'' of
8 bytes to take into account the 8 bytes used to encode the length of
data processed in SHA-1. As the comment in line 159 suggests, the
computation of `getDigestBlockCount` ``assumes a minimum of 1 pad byte''.
I do not understand this sentence in the context: I know that
`fullLength` is one larger than the maximum message size (for a given
raw decrypted plaintext length) because it has one byte for the padding
size and I believe that SHA-1 always adds at least one byte of padding
before appending the 8 bytes of length information which means the
overhead is actually 9 byte?
When considering the call to `getDigestBlockCount(headerLength + length)`,
the `length` is exactly the current message size without an additional
byte for the padding which means that the assumption of ``1 pad byte''
... as I am slightly confused about this I would like to know how the
`int extra` calculation works exactly and greatly appreciate help from
everyone who can shed some light on this.