Bump the maximum number of iterations to recover (p,q) given (n,e,d) to
increase the chance that the algorithm succeeds. The algorithm used is a
probabilistic one with a 1/2 chance of finding the right value in each
iteration, so it's likely that only a few iterations are needed.

However, in some extreme cases this may still fail. Bumping the maximum
number allow the algorithm to correctly find the right values for these
cases. This changes bumps the number of iterations from 50 to 500 (the
value 'a' is increased by 2 in each step), and hence reduces the chance
of failure from 2**-50 to 2**-500.

Note that this change does *not* result in a performance degradation.

In order to speed up as much as possible the GHASH,
the current implementation expands the 16 byte hash key
(H) into a table of 64 KBytes. However, that is sensitive
to cache-based timing attacks.

If we assume that access to data inside the same cache line
is constant-time (likely), fitting a table item into a cache
line may help against the attacks.

This patch reduce the pre-computed table from 64K to 4K
and aligns every item to a 32 byte boundary (since most modern
CPUs have cache line of that size or larger).

This patch will reduce the overall performance.

This patch also reverts commit 965871a727 ("GCM mode:
Optimize key setup for GCM mode") since I actually
got conflicting benchmark results.