The change you suggest seems reasonable to me but you'd need to fully comb through all of MPI to make sure that there is no other code that relies on the current idiotic behaviour of those two functions - for this sort of reason I honestly avoided modifying MPI unless I really, really had to (i.e. it was broken in some part I'm using).

]]>-->

But, the limbs that are

/* ensure that a < n-1 by making a maximum nbits-1 long:

* clear all bits above nbits-2 in a

* keep value of bit nbits-2 in a as it was

*/

if (mpi_test_bit(a, nbits - 2))

mpi_set_highbit(a, nbits - 2);

else

mpi_clear_highbit(a, nbits - 2);

Seem to be equivalent to:

mpi_clear_highbit(a, nbits - 1);

Also, the whole sizing / resizing in mpi_clear_highbit / mpi_set_highbit is suspicious. It seems to be implemented to allow for clear/set highbits in limbs before the last limp (and also after the last limb in case of 'mpi_set_highbit'). But, the limbs that are are not cleared. So if you do a clear (or set) on bit 63 of a 128 bit MPI number (i.e. limb 0 of the 2 limbs MPI). The MPI number will now report to have 1 limb and 2 allocated limbs. Then doing a set_highbit on bit 120 of the MPI number will resuse the second limb (which is still filled with whatever that was there). For example:

byte buf[16];

int i = 0;

for(i = 0; i < 16; i ++) {

buf[i] = 0xff;

}

```
``` printf("mpi_clear_highbit / mpi_set_highbit test\n");

MPI t = mpi_alloc( 2 );

mpi_set_buffer( t, buf, 16, 0);

mpi_print( stdout, t, 1);

mpi_clear_highbit(t, 62);

` printf("\n");`

mpi_print( stdout, t, 1);

printf("\n");

mpi_set_highbit(t, 120);

mpi_print( stdout, t, 1);

This can be fixed by clearing the resused limbs in mpi_set_highbit.

]]>By the looks of it and as per log discussion there is at some point a "80 cols format applied on everything" patch looming too.

]]>“read, re-read and understand TAOCP” - Knuth's book is a must, yes and for this reason alone I'll add it. But I highly suspect that one who fails to get the issue there is likely to have to go even further back on various basics, not even all of them programming-related even so basically I can't say generically where they need to start. That's really why I did not give a list there.

"technically it’s incorrect to say “6 bits will always be 1” ;" - Right. I had in mind the 2 primes, hence 6 bits that contribute to N rather than 6 bits in N itself. I'll re-phrase that more clearly there, thank you.

"Smaller lower bound, isn’t it ?" - It gets confusing, doesn't it? The probability error for M-R has an upper bound that is (1/4)^nwitnesses. If you increase nwitnesses, this upper bound of the probability gets smaller. All you can ever do is lower the maximum probability of error. So it is correct as it is but a bit of an odd-shape for head, will re-phrase.

"As in, real prime number generator ? Nice lol." - Works. Was "random" in my mind, as written in first para but double entendre is even better, as always (rng is random number generator, rpng is random prime number generator, trng is fine, trpng seems a bit too much).

]]>mpi_set_bit( output, 0 ); /* set bottom bit to unsure odd number */

Should be ensure.

go and read some basic books

"read, re-read *and understand* TAOCP" ? or what, add K&R in there ? steele's 2002 thing maybe too ?

(although of those 4096 bits there will be only 4090 randomly-set bits as the other 6 bits are always 1)

technically it's incorrect to say "6 bits will always be 1" ; it's the case that the first and the last bit of N are always 1 ; and a further number of bits are subtly affected (ie, biased) by the p, q masks.

gain at least some smaller upper bound for the error probability

Smaller lower bound, isn't it ?

To see the new rpng in action

As in, real prime number generator ? Nice lol.

I ended up simplifying the configuration of the entropy source

Specifically : moved to raw modem controls ; to /* comment style ; removed 0.1s delay that was there I dunno why.

]]>