multiplicative inverse computations on binary galois fields yield partial result when sampled

I want to compute the multiplicative inverse of 0x2 over $GF(2^{233})$ in hardware.

To do so, I compute $a^{-1} = (a^{2^{m-1}-1})^{2}$. Here's the result of that computation: 0x10000000000000000000000000000000000000002000000000000000000 (where the left-most 1 is bit index 233, not 232).

I verify that I get 1 by multiplying it with the initial number using a binary Karatsuba multiplier.

I'm also able to verify that I can perform a point multiplication over SECT233R1 against this python library.

Here's my question. The result of point multiplication on my hardware is coherent with that of the python library (point multiplication $Q = k*G$), but the result of just the inverse sub-module isn't.

For example, if I use the hazmat math library, I get the inverse of 0x2 to be 0x800000000000000000000000000009f4ba7397c53491018e9301e7f06c. (the left-most 1 is in 0x8 which is 0b0100 which is the 232th bit)

Here's how I do that:

value_S = 0x2
object_S = ec.derive_private_key(value_S, ec.SECT233R1(), default_backend())
object_SINV = ops.BN_MOD_INVERSE(object_S)
vals = object_SINV.private_numbers()
print (f"SINV value: {hex(vals.private_value)}.")

My question is why I don't see the same value for $s^{-1}$ in my hardware, and in the python library, when they both give the same result for point multiplication.

Can someone please help me understand what I'm missing? Thanks in advance!

BN_MOD_INVERSE operates in the multiplicative subgroup of the field $\mathbb Z_n$ where $n$ is the order of the Elliptic Curve group sect233r1, not in the multiplicative subgroup of the field $\operatorname{GF}(2^{233})$ with irreducible polynomial $x^{233}+x^{74}+1$.

This explains the discrepancy.

I eventually want to perform ECDSA verification and that requires me to compute $s^{-1}\bmod n$

Yes it does. That's one pitfall of ECDSA over EC-Schnorr signature, which does not.

I would also like to understand what computations on the result of $a^{-1} = a^{2^{m-1}-1}$ would be required to bring me to the result obtained using BN_MOD_INVERSE.

I have bad news: computing the first is essentially irrelevant to obtaining the second. The multiplicative subgroup of fields $\mathbb Z_n$ and $\operatorname{GF}(2^{233})$ just have nothing to do. In particular the former uses carry in multiplication, which make hardware implementation much more complex.

The good news is that the computation of $s^{-1}\bmod n$ can be reduced to a small percentage of the cost of ECDSA verification by using appropriate algorithms, even if done in software. One suitable algorithm is there. That can be adapted to hardware by noting that estimating quotients by default leaves the algorithm correct, and still fast even if we round down quotient estimates to the nearest power of two.

Update: the Binary Extended GCD algorithm likely is simpler in hardware, because it requires no quotient estimation whatsoever; see this.