I donâ€™t think they are testing for small primes at all. Maybe youâ€™ve made the same mistake in understanding as I did originally because of your â€śsmall primesâ€ť priming (no pun intended).

Again, look what it does for 11. Let us suppose our modulus is M.

The code divides M by 11 and finds the remainder, then it left shifts 1 by this number, so that will produce one of the values 1, 2, 4, 8, 16 and so on up to 1024.

Then it does a bitwise AND between this value and the corresponding big number from prints which is 1026. If and only if this bitwise AND gives a zero result it concludes this key was NOT generated by an Infineon device and so itâ€™s not interesting. This even includes the small primes.

Try M = 77, which is definitely divisible by a small prime

```
M := 77
M % 11 = 0
1 << 0 = 1
1 & 1026 = 0
```

Not Infineon. They donâ€™t care itâ€™s divisible by a small prime, the Infineon devices donâ€™t spit such moduli, they have a decent primarily tester inside them, itâ€™s just that theyâ€™re broken in some other way.

So what *does* fail the test and cause it to keep trying? That technical report I linked illustrates, the first small prime for which itâ€™s interesting is 11 as I mentioned earlier, Infineon devices never pick a modulus which has remainder 2, 3, 4, 5, 6, 7, 8 or 9 when divided by 11, itâ€™s always 1 or 10. Hence the choice of 1026 which is (1 << 10) + (1 << 1).

The *reason* itâ€™s doing this seems to be that if M mod 11 in { 1, 10 } that means MÂ˛ mod 11 is 1 because of how modulo arithmetic works. For each small prime s thereâ€™s some small exponent a such that M^a mod s = 1 for *all* Infineon moduli, and the complicated mess in the sample code relates to that fact in an obscure fashion. So probably a much simpler and better test is possible, it may make sense to wait for the finished paper rather than speculate further though.