3
$\begingroup$

I have the following questions about the construction of J0 when is not equal to 96 bits, $s= 128\big\lceil \operatorname{len}(\text{IV})/128\big\rceil-\operatorname{len}(\text{IV})$

For example if my IV is equal to 1, Calculating with Len would be 8-bit result, If we subtract, $\operatorname{len}(IV) / 128$ and calculating the result is 1 subtracted by 8 would be 7, Real number 1 or it is taken as 8-bit byte, and it would be and the rest would be 0?

And the 128 which is outside what is the function, multiply? And read the steps, but reading the explanation of the document and reading the formulas confuses me.

If $\operatorname{len}(\text{IV}) ≠ 96$, then let $s= 128\big\lceil \operatorname{len}(\text{IV})/128 \big\rceil-\operatorname{len}(\text{IV})$, and let $J_0=\operatorname{GHASH}(\text{IV}||0s+64||[\operatorname{len}(\text{IV})]64)$.

$\endgroup$
3
$\begingroup$

Yes, the initial 128 is multiplication and it is performed before the subtraction.

OK, so if $\operatorname{len}(IV) = 1$ in bits then $$s= 128\big\lceil\operatorname{len}(IV)/128\big\rceil-\operatorname{len}(IV)$$ would be $$s= 128 \cdot 1 - 1 = 128 - 1 = 127$$

However, if you encode it as a single byte then $$s= 128 \cdot 1 - 8 = 128 - 8 = 120$$.

Note that any IV size between 0 exclusive and 128 inclusive will let $\big\lceil \operatorname{len}(IV)/128\big\rceil$ evaluate to 1, as the division result is in between 0 exclusive and 1 inclusive.

The IV is generally delivered as byte array as implementations generally do not operate on bits, even if the speficiation does specify the algorithm in bits. So generally delivering just one bit is not possible. This means that the most significant (leftmost bits) of the byte or bytes are included in the calculation even if they set to 0. The IV is handled as a string of bits, not as a number within the specification. So lets assume a single byte with value 00000001 in bits.


For the second part of the scheme to calculate $J_0$ we have $$J_0=\operatorname{GHASH}_H(IV||0^{s+64}||\big[\operatorname{len}(IV)\big]_{64})$$ which means the $\operatorname{GHASH}$ using $H$ over the one byte IV concatenated by $s + 64$ bits (184 bits or 23 bytes) set to zero and then the length of the IV created as static, big endian unsigned encoding of 8 bytes. If you combine the sizes of the fields you'll get a nice 32 bytes: $1 + 23 + 8 = 32$, which is handled perfectly well by GHASH that requires 128 bit / 16 byte block size.

The result will be, the GHASH over (in hexadecimals, two characers per byte):

01_000000_00000000 00000000_00000000 00000000_00000000 00000000_00000001 
$\endgroup$
3
$\begingroup$

Everything here is counted in bits, not bytes. The GCM specification is at least consistent about using bits. Try not thinking about bytes, as these would only increase confusion.

$\lceil\text{len}(IV)/128\rceil$ is: "length of IV, divided by 128, rounded up". So this is the length of IV, counted in number of 128-bit blocks. By multiplying it by 128, you get the length of the smallest sequence of bits that is obtained by appending extra bits to the IV until you get a length with a multiple of 128.

Thus, the expression for $s$: $$ s = 128 \lceil\text{len}(IV)/128\rceil - \text{len}(IV) $$ really is: the number of bits you must add to the IV in order to get a length which is a multiple of 128.

The underlying idea here is that GHASH can process only data by blocks of 128 bits, so some extra bits must be appended to the IV. Moreover, the original IV length (before padding) must be encoded there, to avoid some attacks (and/or improve security proofs). Thus, the scheme is: append some bits of value zero, then the encoding of the length of the IV over 64 bits. The number of bits of value zero must be between 64 and 191, and also such that the total length (with padding) is a multiple of 128. If you call the number of extra bits of value zero "$s+64$", then $s$ is the value computed by the formula above.

For instance, if your IV has length $209$ bits, then you get $s = 47$ (you need $47$ extra bits to reach the next multiple of $128$, which, in this case, is $256$). Thus, the padding will add $s+64 = 111$ bits of value zero, then the encoding of the original IV length ($209$ bits) over $64$ bits. The number of extra bits will then be $s+64+64 = 175$, for a grand total after padding of $209 + 175 = 384$ bits, which is indeed a multiple of $128$ (hurray!).

$\endgroup$
  • $\begingroup$ Thanks, He doesn't mark the two as correct answers, but is it the same. $\endgroup$ – user3127939 May 21 '18 at 13:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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