Save the last cycle in GCM GHASH calculation I need to implement GCM GHASH in hardware, using FPGA. The data bus is 640 bits, so I will use 5 adder/multiplier blocks in parallel. The message size is fixed and AAD is 0. 

A little example: message = 5 x 640 bits.

cycle 1: process 640 bits (add/multiply)
cycle 2: process 640 bits (add/multiply)
cycle 3: process 640 bits (add/multiply)
cycle 4: process 640 bits (add/multiply)
cycle 5: process 640 bits (add/multiply)
cycle 6: process Len 0||C (add/multiply) and xor all results


In the above example, for 5 cycles of data I need 6 cycles to calculate GHASH. The extra cycle is necessary to insert LEN(0||C) in the data flow.

Problem is, I have a continuous data flow and I cannot interrupt it to insert LEN 0||C.

Is it possible to manipulate the GHASH in a way that the processing of LEN(0||C) could be made in advance and just added to the end of processing, saving one processing cycle?



Just to explain better, my architecture is based on this paper:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&amp;arnumber=5619894&amp;queryText%3DFPGA+parallel-pipelined+AES-GCM+core+for+100G+Ethernet+applications

The add/multiplied data from each adder/multiplicator is saved on a Q memory that have 4 positions. So, at the end of the data, the Q memories positions are xored. The 5 results are then xored and we have the GHASH(CYPHER_TEXT).
I have a C model that processes the len_C adding it to the end of the flow, so I know the GHASH(CYPHER_TEXT) result.

In my verilog model, I have almost the same Q memories contents at the end of the data processing, the only difference is caused by the len_c processing.
The values are:


C model ghash: 0x72a61c9521a6f05da7b16d8fb6b2e115
Verilog model GHASH without processing Len_C: 0x3f1cdbad43034cbfc4d09060e08678e7
My Len_c (bit mirrored to work with my architecture): 0x00980000000000000000000000000000
H: 0x6909696eb6211e31212d7d0a3e07b836


I tried the calculations you proposed but it not works. You guys could please take a look?
Well, the GCM tag can be rearranged as $Tag = (Len(C, A) \times H) \oplus \textit{Other Stuff}$; if the length of your ciphertext (and additional authentication data) is consistent, you could precompute $Len(C, A) \times H$, and xor that in along with everything else in the final step.

One note: the (add/multiply) that you do in cycle 6 has the side effect of multiplying the result of the GHASH from the ciphertext by $H$; if you eliminate that multiply, you'd need to somehow get the same effect.