2020-02-23 14:30:03 +00:00
|
|
|
/*
|
|
|
|
* primecandidate.c: implementation of the PrimeCandidateSource
|
|
|
|
* abstraction declared in sshkeygen.h.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <assert.h>
|
|
|
|
#include "ssh.h"
|
|
|
|
#include "mpint.h"
|
|
|
|
#include "mpunsafe.h"
|
|
|
|
#include "sshkeygen.h"
|
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
struct avoid {
|
|
|
|
unsigned mod, res;
|
|
|
|
};
|
|
|
|
|
2020-02-23 14:30:03 +00:00
|
|
|
struct PrimeCandidateSource {
|
|
|
|
unsigned bits;
|
2020-02-29 06:46:13 +00:00
|
|
|
bool ready, try_sophie_germain;
|
PrimeCandidateSource: add one-shot mode.
If you want to generate a Sophie Germain / safe prime pair with this
code, then after you've made p, you need to test the primality of
2p+1.
The easiest way to do that is to make a PrimeCandidateSource that is
so constrained as to only be able to deliver 2p+1 as a candidate, and
then run the ordinary prime generation system. The problem is that the
prime generation loops forever, so if 2p+1 _isn't_ prime, it will just
keep testing the same number over and over again and failing the test.
To solve this, I add a 'one-shot mode' to the PrimeCandidateSource
itself, which will cause it to return NULL if asked to generate a
second candidate. Then the prime-generation loops all detect that and
return NULL in turn. However, for clients that _don't_ set a pcs into
one-shot mode, the API remains unchanged: pcs_generate will not return
until it's found a prime (by its own criteria).
This feels like a bit of a bodge, API-wise. But the other two obvious
approaches turn out more awkward.
One option is to extract the Pockle from the PrimeGenerationContext
and use that to directly test primality of 2p+1 based on p - but that
way you don't get to _probabilistically_ generate safe primes, because
that kind of PGC has no Pockle in the first place. (And you can't make
one separately, because you can't convince it that an only
probabilistically generated p is prime!)
Another option is to add a test() method to PrimeGenerationPolicy,
that sits alongside generate(). Then, having generated p, you just
_test_ 2p+1. But then in the provable case you have to explain to it
that it should use p as part of the proof, so that API would get
awkward in its own way.
So this is actually the least disruptive way to do it!
2020-02-29 06:47:12 +00:00
|
|
|
bool one_shot, thrown_away_my_shot;
|
2020-02-23 14:30:03 +00:00
|
|
|
|
|
|
|
/* We'll start by making up a random number strictly less than this ... */
|
|
|
|
mp_int *limit;
|
|
|
|
|
|
|
|
/* ... then we'll multiply by 'factor', and add 'addend'. */
|
|
|
|
mp_int *factor, *addend;
|
|
|
|
|
|
|
|
/* Then we'll try to add a small multiple of 'factor' to it to
|
|
|
|
* avoid it being a multiple of any small prime. Also, for RSA, we
|
|
|
|
* may need to avoid it being _this_ multiple of _this_: */
|
|
|
|
unsigned avoid_residue, avoid_modulus;
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
|
|
|
|
/* Once we're actually running, this will be the complete list of
|
|
|
|
* (modulus, residue) pairs we want to avoid. */
|
|
|
|
struct avoid *avoids;
|
|
|
|
size_t navoids, avoidsize;
|
2020-02-29 06:33:26 +00:00
|
|
|
|
|
|
|
/* List of known primes that our number will be congruent to 1 modulo */
|
|
|
|
mp_int **kps;
|
|
|
|
size_t nkps, kpsize;
|
2020-02-23 14:30:03 +00:00
|
|
|
};
|
|
|
|
|
2020-02-24 19:09:08 +00:00
|
|
|
PrimeCandidateSource *pcs_new_with_firstbits(unsigned bits,
|
|
|
|
unsigned first, unsigned nfirst)
|
2020-02-23 14:30:03 +00:00
|
|
|
{
|
|
|
|
PrimeCandidateSource *s = snew(PrimeCandidateSource);
|
|
|
|
|
|
|
|
assert(first >> (nfirst-1) == 1);
|
|
|
|
|
|
|
|
s->bits = bits;
|
|
|
|
s->ready = false;
|
2020-02-29 06:46:13 +00:00
|
|
|
s->try_sophie_germain = false;
|
PrimeCandidateSource: add one-shot mode.
If you want to generate a Sophie Germain / safe prime pair with this
code, then after you've made p, you need to test the primality of
2p+1.
The easiest way to do that is to make a PrimeCandidateSource that is
so constrained as to only be able to deliver 2p+1 as a candidate, and
then run the ordinary prime generation system. The problem is that the
prime generation loops forever, so if 2p+1 _isn't_ prime, it will just
keep testing the same number over and over again and failing the test.
To solve this, I add a 'one-shot mode' to the PrimeCandidateSource
itself, which will cause it to return NULL if asked to generate a
second candidate. Then the prime-generation loops all detect that and
return NULL in turn. However, for clients that _don't_ set a pcs into
one-shot mode, the API remains unchanged: pcs_generate will not return
until it's found a prime (by its own criteria).
This feels like a bit of a bodge, API-wise. But the other two obvious
approaches turn out more awkward.
One option is to extract the Pockle from the PrimeGenerationContext
and use that to directly test primality of 2p+1 based on p - but that
way you don't get to _probabilistically_ generate safe primes, because
that kind of PGC has no Pockle in the first place. (And you can't make
one separately, because you can't convince it that an only
probabilistically generated p is prime!)
Another option is to add a test() method to PrimeGenerationPolicy,
that sits alongside generate(). Then, having generated p, you just
_test_ 2p+1. But then in the provable case you have to explain to it
that it should use p as part of the proof, so that API would get
awkward in its own way.
So this is actually the least disruptive way to do it!
2020-02-29 06:47:12 +00:00
|
|
|
s->one_shot = false;
|
|
|
|
s->thrown_away_my_shot = false;
|
2020-02-23 14:30:03 +00:00
|
|
|
|
2020-02-29 06:33:26 +00:00
|
|
|
s->kps = NULL;
|
|
|
|
s->nkps = s->kpsize = 0;
|
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
s->avoids = NULL;
|
|
|
|
s->navoids = s->avoidsize = 0;
|
|
|
|
|
2020-02-23 14:30:03 +00:00
|
|
|
/* Make the number that's the lower limit of our range */
|
|
|
|
mp_int *firstmp = mp_from_integer(first);
|
|
|
|
mp_int *base = mp_lshift_fixed(firstmp, bits - nfirst);
|
|
|
|
mp_free(firstmp);
|
|
|
|
|
|
|
|
/* Set the low bit of that, because all (nontrivial) primes are odd */
|
|
|
|
mp_set_bit(base, 0, 1);
|
|
|
|
|
|
|
|
/* That's our addend. Now initialise factor to 2, to ensure we
|
|
|
|
* only generate odd numbers */
|
|
|
|
s->factor = mp_from_integer(2);
|
|
|
|
s->addend = base;
|
|
|
|
|
|
|
|
/* And that means the limit of our random numbers must be one
|
|
|
|
* factor of two _less_ than the position of the low bit of
|
|
|
|
* 'first', because we'll be multiplying the random number by
|
|
|
|
* 2 immediately afterwards. */
|
|
|
|
s->limit = mp_power_2(bits - nfirst - 1);
|
|
|
|
|
|
|
|
/* avoid_modulus == 0 signals that there's no extra residue to avoid */
|
|
|
|
s->avoid_residue = 1;
|
|
|
|
s->avoid_modulus = 0;
|
|
|
|
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
2020-02-24 19:09:08 +00:00
|
|
|
PrimeCandidateSource *pcs_new(unsigned bits)
|
|
|
|
{
|
|
|
|
return pcs_new_with_firstbits(bits, 1, 1);
|
|
|
|
}
|
|
|
|
|
2020-02-23 14:30:03 +00:00
|
|
|
void pcs_free(PrimeCandidateSource *s)
|
|
|
|
{
|
|
|
|
mp_free(s->limit);
|
|
|
|
mp_free(s->factor);
|
|
|
|
mp_free(s->addend);
|
2020-02-29 06:33:26 +00:00
|
|
|
for (size_t i = 0; i < s->nkps; i++)
|
|
|
|
mp_free(s->kps[i]);
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
sfree(s->avoids);
|
2020-02-29 06:33:26 +00:00
|
|
|
sfree(s->kps);
|
2020-02-23 14:30:03 +00:00
|
|
|
sfree(s);
|
|
|
|
}
|
|
|
|
|
2020-02-29 06:46:13 +00:00
|
|
|
void pcs_try_sophie_germain(PrimeCandidateSource *s)
|
|
|
|
{
|
|
|
|
s->try_sophie_germain = true;
|
|
|
|
}
|
|
|
|
|
PrimeCandidateSource: add one-shot mode.
If you want to generate a Sophie Germain / safe prime pair with this
code, then after you've made p, you need to test the primality of
2p+1.
The easiest way to do that is to make a PrimeCandidateSource that is
so constrained as to only be able to deliver 2p+1 as a candidate, and
then run the ordinary prime generation system. The problem is that the
prime generation loops forever, so if 2p+1 _isn't_ prime, it will just
keep testing the same number over and over again and failing the test.
To solve this, I add a 'one-shot mode' to the PrimeCandidateSource
itself, which will cause it to return NULL if asked to generate a
second candidate. Then the prime-generation loops all detect that and
return NULL in turn. However, for clients that _don't_ set a pcs into
one-shot mode, the API remains unchanged: pcs_generate will not return
until it's found a prime (by its own criteria).
This feels like a bit of a bodge, API-wise. But the other two obvious
approaches turn out more awkward.
One option is to extract the Pockle from the PrimeGenerationContext
and use that to directly test primality of 2p+1 based on p - but that
way you don't get to _probabilistically_ generate safe primes, because
that kind of PGC has no Pockle in the first place. (And you can't make
one separately, because you can't convince it that an only
probabilistically generated p is prime!)
Another option is to add a test() method to PrimeGenerationPolicy,
that sits alongside generate(). Then, having generated p, you just
_test_ 2p+1. But then in the provable case you have to explain to it
that it should use p as part of the proof, so that API would get
awkward in its own way.
So this is actually the least disruptive way to do it!
2020-02-29 06:47:12 +00:00
|
|
|
void pcs_set_oneshot(PrimeCandidateSource *s)
|
|
|
|
{
|
|
|
|
s->one_shot = true;
|
|
|
|
}
|
|
|
|
|
2020-02-23 14:30:03 +00:00
|
|
|
static void pcs_require_residue_inner(PrimeCandidateSource *s,
|
|
|
|
mp_int *mod, mp_int *res)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* We already have a factor and addend. Ensure this one doesn't
|
|
|
|
* contradict it.
|
|
|
|
*/
|
|
|
|
mp_int *gcd = mp_gcd(mod, s->factor);
|
|
|
|
mp_int *test1 = mp_mod(s->addend, gcd);
|
|
|
|
mp_int *test2 = mp_mod(res, gcd);
|
|
|
|
assert(mp_cmp_eq(test1, test2));
|
|
|
|
mp_free(test1);
|
|
|
|
mp_free(test2);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reduce our input factor and addend, which are constraints on
|
|
|
|
* the ultimate output number, so that they're constraints on the
|
|
|
|
* initial cofactor we're going to make up.
|
|
|
|
*
|
|
|
|
* If we're generating x and we want to ensure ax+b == r (mod m),
|
|
|
|
* how does that work? We've already checked that b == r modulo g
|
|
|
|
* = gcd(a,m), i.e. r-b is a multiple of g, and so are a and m. So
|
|
|
|
* let's write a=gA, m=gM, (r-b)=gR, and then we can start by
|
|
|
|
* dividing that off:
|
|
|
|
*
|
|
|
|
* ax == r-b (mod m )
|
|
|
|
* => gAx == gR (mod gM)
|
|
|
|
* => Ax == R (mod M)
|
|
|
|
*
|
|
|
|
* Now the moduli A,M are coprime, which makes things easier.
|
|
|
|
*
|
|
|
|
* We're going to need to generate the x in this equation by
|
|
|
|
* generating a new smaller value y, multiplying it by M, and
|
|
|
|
* adding some constant K. So we have x = My + K, and we need to
|
|
|
|
* work out what K will satisfy the above equation. In other
|
|
|
|
* words, we need A(My+K) == R (mod M), and the AMy term vanishes,
|
|
|
|
* so we just need AK == R (mod M). So our congruence is solved by
|
|
|
|
* setting K to be R * A^{-1} mod M.
|
|
|
|
*/
|
|
|
|
mp_int *A = mp_div(s->factor, gcd);
|
|
|
|
mp_int *M = mp_div(mod, gcd);
|
|
|
|
mp_int *Rpre = mp_modsub(res, s->addend, mod);
|
|
|
|
mp_int *R = mp_div(Rpre, gcd);
|
|
|
|
mp_int *Ainv = mp_invert(A, M);
|
|
|
|
mp_int *K = mp_modmul(R, Ainv, M);
|
|
|
|
|
|
|
|
mp_free(gcd);
|
|
|
|
mp_free(Rpre);
|
|
|
|
mp_free(Ainv);
|
|
|
|
mp_free(A);
|
|
|
|
mp_free(R);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* So we know we have to transform our existing (factor, addend)
|
|
|
|
* pair into (factor * M, addend * factor * K). Now we just need
|
|
|
|
* to work out what the limit should be on the random value we're
|
|
|
|
* generating.
|
|
|
|
*
|
|
|
|
* If we need My+K < old_limit, then y < (old_limit-K)/M. But the
|
|
|
|
* RHS is a fraction, so in integers, we need y < ceil of it.
|
|
|
|
*/
|
|
|
|
assert(!mp_cmp_hs(K, s->limit));
|
|
|
|
mp_int *dividend = mp_add(s->limit, M);
|
|
|
|
mp_sub_integer_into(dividend, dividend, 1);
|
|
|
|
mp_sub_into(dividend, dividend, K);
|
|
|
|
mp_free(s->limit);
|
|
|
|
s->limit = mp_div(dividend, M);
|
|
|
|
mp_free(dividend);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now just update the real factor and addend, and we're done.
|
|
|
|
*/
|
|
|
|
|
|
|
|
mp_int *addend_old = s->addend;
|
|
|
|
mp_int *tmp = mp_mul(s->factor, K); /* use the _old_ value of factor */
|
|
|
|
s->addend = mp_add(s->addend, tmp);
|
|
|
|
mp_free(tmp);
|
|
|
|
mp_free(addend_old);
|
|
|
|
|
|
|
|
mp_int *factor_old = s->factor;
|
|
|
|
s->factor = mp_mul(s->factor, M);
|
|
|
|
mp_free(factor_old);
|
|
|
|
|
|
|
|
mp_free(M);
|
|
|
|
mp_free(K);
|
|
|
|
s->factor = mp_unsafe_shrink(s->factor);
|
|
|
|
s->addend = mp_unsafe_shrink(s->addend);
|
|
|
|
s->limit = mp_unsafe_shrink(s->limit);
|
|
|
|
}
|
|
|
|
|
|
|
|
void pcs_require_residue(PrimeCandidateSource *s,
|
|
|
|
mp_int *mod, mp_int *res_orig)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Reduce the input residue to its least non-negative value, in
|
|
|
|
* case it was given as a larger equivalent value.
|
|
|
|
*/
|
|
|
|
mp_int *res_reduced = mp_mod(res_orig, mod);
|
|
|
|
pcs_require_residue_inner(s, mod, res_reduced);
|
|
|
|
mp_free(res_reduced);
|
|
|
|
}
|
|
|
|
|
|
|
|
void pcs_require_residue_1(PrimeCandidateSource *s, mp_int *mod)
|
|
|
|
{
|
|
|
|
mp_int *res = mp_from_integer(1);
|
|
|
|
pcs_require_residue(s, mod, res);
|
|
|
|
mp_free(res);
|
|
|
|
}
|
|
|
|
|
2020-02-29 06:33:26 +00:00
|
|
|
void pcs_require_residue_1_mod_prime(PrimeCandidateSource *s, mp_int *mod)
|
|
|
|
{
|
|
|
|
pcs_require_residue_1(s, mod);
|
|
|
|
|
|
|
|
sgrowarray(s->kps, s->kpsize, s->nkps);
|
|
|
|
s->kps[s->nkps++] = mp_copy(mod);
|
|
|
|
}
|
|
|
|
|
2020-02-23 14:30:03 +00:00
|
|
|
void pcs_avoid_residue_small(PrimeCandidateSource *s,
|
|
|
|
unsigned mod, unsigned res)
|
|
|
|
{
|
|
|
|
assert(!s->avoid_modulus); /* can't cope with more than one */
|
|
|
|
s->avoid_modulus = mod;
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
s->avoid_residue = res % mod; /* reduce, just in case */
|
|
|
|
}
|
|
|
|
|
|
|
|
static int avoid_cmp(const void *av, const void *bv)
|
|
|
|
{
|
|
|
|
const struct avoid *a = (const struct avoid *)av;
|
|
|
|
const struct avoid *b = (const struct avoid *)bv;
|
|
|
|
return a->mod < b->mod ? -1 : a->mod > b->mod ? +1 : 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static uint64_t invert(uint64_t a, uint64_t m)
|
|
|
|
{
|
|
|
|
int64_t v0 = a, i0 = 1;
|
|
|
|
int64_t v1 = m, i1 = 0;
|
|
|
|
while (v0) {
|
|
|
|
int64_t tmp, q = v1 / v0;
|
|
|
|
tmp = v0; v0 = v1 - q*v0; v1 = tmp;
|
|
|
|
tmp = i0; i0 = i1 - q*i0; i1 = tmp;
|
|
|
|
}
|
|
|
|
assert(v1 == 1 || v1 == -1);
|
|
|
|
return i1 * v1;
|
2020-02-23 14:30:03 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void pcs_ready(PrimeCandidateSource *s)
|
|
|
|
{
|
|
|
|
/*
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
* List all the small (modulus, residue) pairs we want to avoid.
|
|
|
|
*/
|
|
|
|
|
|
|
|
init_smallprimes();
|
|
|
|
|
|
|
|
#define ADD_AVOID(newmod, newres) do { \
|
|
|
|
sgrowarray(s->avoids, s->avoidsize, s->navoids); \
|
|
|
|
s->avoids[s->navoids].mod = (newmod); \
|
|
|
|
s->avoids[s->navoids].res = (newres); \
|
|
|
|
s->navoids++; \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
unsigned limit = (mp_hs_integer(s->addend, 65536) ? 65536 :
|
|
|
|
mp_get_integer(s->addend));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Don't be divisible by any small prime, or at least, any prime
|
|
|
|
* smaller than our output number might actually manage to be. (If
|
|
|
|
* asked to generate a really small prime, it would be
|
|
|
|
* embarrassing to rule out legitimate answers on the grounds that
|
|
|
|
* they were divisible by themselves.)
|
|
|
|
*/
|
|
|
|
for (size_t i = 0; i < NSMALLPRIMES && smallprimes[i] < limit; i++)
|
|
|
|
ADD_AVOID(smallprimes[i], 0);
|
|
|
|
|
2020-02-29 06:46:13 +00:00
|
|
|
if (s->try_sophie_germain) {
|
|
|
|
/*
|
|
|
|
* If we're aiming to generate a Sophie Germain prime (i.e. p
|
|
|
|
* such that 2p+1 is also prime), then we also want to ensure
|
|
|
|
* 2p+1 is not congruent to 0 mod any small prime, because if
|
|
|
|
* it is, we'll waste a lot of time generating a p for which
|
|
|
|
* 2p+1 can't possibly work. So we have to avoid an extra
|
|
|
|
* residue mod each odd q.
|
|
|
|
*
|
|
|
|
* We can simplify: 2p+1 == 0 (mod q)
|
|
|
|
* => 2p == -1 (mod q)
|
|
|
|
* => p == -2^{-1} (mod q)
|
|
|
|
*
|
|
|
|
* There's no need to do Euclid's algorithm to compute those
|
|
|
|
* inverses, because for any odd q, the modular inverse of -2
|
|
|
|
* mod q is just (q-1)/2. (Proof: multiplying it by -2 gives
|
|
|
|
* 1-q, which is congruent to 1 mod q.)
|
|
|
|
*/
|
|
|
|
for (size_t i = 0; i < NSMALLPRIMES && smallprimes[i] < limit; i++)
|
|
|
|
if (smallprimes[i] != 2)
|
|
|
|
ADD_AVOID(smallprimes[i], (smallprimes[i] - 1) / 2);
|
|
|
|
}
|
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
/*
|
|
|
|
* Finally, if there's a particular modulus and residue we've been
|
|
|
|
* told to avoid, put it on the list.
|
|
|
|
*/
|
|
|
|
if (s->avoid_modulus)
|
|
|
|
ADD_AVOID(s->avoid_modulus, s->avoid_residue);
|
|
|
|
|
|
|
|
#undef ADD_AVOID
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sort our to-avoid list by modulus. Partly this is so that we'll
|
|
|
|
* check the smaller moduli first during the live runs, which lets
|
|
|
|
* us spot most failing cases earlier rather than later. Also, it
|
|
|
|
* brings equal moduli together, so that we can reuse the residue
|
|
|
|
* we computed from a previous one.
|
|
|
|
*/
|
|
|
|
qsort(s->avoids, s->navoids, sizeof(*s->avoids), avoid_cmp);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Next, adjust each of these moduli to take account of our factor
|
|
|
|
* and addend. If we want factor*x+addend to avoid being congruent
|
|
|
|
* to 'res' modulo 'mod', then x itself must avoid being congruent
|
|
|
|
* to (res - addend) * factor^{-1}.
|
2020-02-23 14:30:03 +00:00
|
|
|
*
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
* If factor == 0 modulo mod, then the answer will have a fixed
|
|
|
|
* residue anyway, so we can discard it from our list to test.
|
2020-02-23 14:30:03 +00:00
|
|
|
*/
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
int64_t factor_m = 0, addend_m = 0, last_mod = 0;
|
|
|
|
|
|
|
|
size_t out = 0;
|
|
|
|
for (size_t i = 0; i < s->navoids; i++) {
|
|
|
|
int64_t mod = s->avoids[i].mod, res = s->avoids[i].res;
|
|
|
|
if (mod != last_mod) {
|
|
|
|
last_mod = mod;
|
|
|
|
addend_m = mp_unsafe_mod_integer(s->addend, mod);
|
|
|
|
factor_m = mp_unsafe_mod_integer(s->factor, mod);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (factor_m == 0) {
|
|
|
|
assert(res != addend_m);
|
|
|
|
continue;
|
|
|
|
}
|
2020-02-23 14:30:03 +00:00
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
res = (res - addend_m) * invert(factor_m, mod);
|
|
|
|
res %= mod;
|
|
|
|
if (res < 0)
|
|
|
|
res += mod;
|
|
|
|
|
|
|
|
s->avoids[out].mod = mod;
|
|
|
|
s->avoids[out].res = res;
|
|
|
|
out++;
|
|
|
|
}
|
|
|
|
|
|
|
|
s->navoids = out;
|
2020-02-23 14:30:03 +00:00
|
|
|
|
|
|
|
s->ready = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
mp_int *pcs_generate(PrimeCandidateSource *s)
|
|
|
|
{
|
|
|
|
assert(s->ready);
|
PrimeCandidateSource: add one-shot mode.
If you want to generate a Sophie Germain / safe prime pair with this
code, then after you've made p, you need to test the primality of
2p+1.
The easiest way to do that is to make a PrimeCandidateSource that is
so constrained as to only be able to deliver 2p+1 as a candidate, and
then run the ordinary prime generation system. The problem is that the
prime generation loops forever, so if 2p+1 _isn't_ prime, it will just
keep testing the same number over and over again and failing the test.
To solve this, I add a 'one-shot mode' to the PrimeCandidateSource
itself, which will cause it to return NULL if asked to generate a
second candidate. Then the prime-generation loops all detect that and
return NULL in turn. However, for clients that _don't_ set a pcs into
one-shot mode, the API remains unchanged: pcs_generate will not return
until it's found a prime (by its own criteria).
This feels like a bit of a bodge, API-wise. But the other two obvious
approaches turn out more awkward.
One option is to extract the Pockle from the PrimeGenerationContext
and use that to directly test primality of 2p+1 based on p - but that
way you don't get to _probabilistically_ generate safe primes, because
that kind of PGC has no Pockle in the first place. (And you can't make
one separately, because you can't convince it that an only
probabilistically generated p is prime!)
Another option is to add a test() method to PrimeGenerationPolicy,
that sits alongside generate(). Then, having generated p, you just
_test_ 2p+1. But then in the provable case you have to explain to it
that it should use p as part of the proof, so that API would get
awkward in its own way.
So this is actually the least disruptive way to do it!
2020-02-29 06:47:12 +00:00
|
|
|
if (s->one_shot) {
|
|
|
|
if (s->thrown_away_my_shot)
|
|
|
|
return NULL;
|
|
|
|
s->thrown_away_my_shot = true;
|
|
|
|
}
|
2020-02-23 14:30:03 +00:00
|
|
|
|
|
|
|
while (true) {
|
|
|
|
mp_int *x = mp_random_upto(s->limit);
|
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
int64_t x_res = 0, last_mod = 0;
|
|
|
|
bool ok = true;
|
2020-02-23 14:30:03 +00:00
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
for (size_t i = 0; i < s->navoids; i++) {
|
|
|
|
int64_t mod = s->avoids[i].mod, avoid_res = s->avoids[i].res;
|
2020-02-23 14:30:03 +00:00
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
if (mod != last_mod) {
|
|
|
|
last_mod = mod;
|
|
|
|
x_res = mp_unsafe_mod_integer(x, mod);
|
2020-02-23 14:30:03 +00:00
|
|
|
}
|
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
if (x_res == avoid_res) {
|
|
|
|
ok = false;
|
|
|
|
break;
|
|
|
|
}
|
2020-02-23 14:30:03 +00:00
|
|
|
}
|
|
|
|
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
if (!ok) {
|
|
|
|
mp_free(x);
|
|
|
|
continue; /* try a new x */
|
|
|
|
}
|
2020-02-23 14:30:03 +00:00
|
|
|
|
|
|
|
/*
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
* We've found a viable x. Make the final output value.
|
2020-02-23 14:30:03 +00:00
|
|
|
*/
|
|
|
|
mp_int *toret = mp_new(s->bits);
|
Rework PrimeCandidateSource without the delta system.
Now we don't even bother with picking an mp_int base value and a small
adjustment; we just generate a random mp_int, and if it's congruent to
anything we want to avoid, throw it away and try again.
This should cause us to select completely uniformly from the candidate
values in the available range. Previously, the delta system was
introducing small skews at the start and end of the range (values very
near there were less likely to turn up because they fell within the
delta radius of a smaller set of base values).
I was worried about doing this because I thought it would be slower,
because of having to do a big pile of 'reduce mp_int mod small thing'
every time round the loop: the virtue of the delta system is that you
can set up the residues of your base value once and then try several
deltas using only normal-sized integer operations. But now I look more
closely, we were computing _all_ the residues of the base point every
time round the loop (several thousand of them), whereas now we're very
likely to be able to throw a candidate away after only two or three if
it's divisible by one of the smallest primes, which are also the ones
most likely to get in the way. So probably it's actually _faster_ than
the old system (although, since uniformity was my main aim, I haven't
timed it, only noticed that it seems to be fast _enough_).
2020-03-01 17:06:04 +00:00
|
|
|
mp_mul_into(toret, x, s->factor);
|
2020-02-23 14:30:03 +00:00
|
|
|
mp_add_into(toret, toret, s->addend);
|
|
|
|
mp_free(x);
|
|
|
|
return toret;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void pcs_inspect(PrimeCandidateSource *pcs, mp_int **limit_out,
|
|
|
|
mp_int **factor_out, mp_int **addend_out)
|
|
|
|
{
|
|
|
|
*limit_out = mp_copy(pcs->limit);
|
|
|
|
*factor_out = mp_copy(pcs->factor);
|
|
|
|
*addend_out = mp_copy(pcs->addend);
|
|
|
|
}
|
2020-02-24 19:09:08 +00:00
|
|
|
|
|
|
|
unsigned pcs_get_bits(PrimeCandidateSource *pcs)
|
|
|
|
{
|
|
|
|
return pcs->bits;
|
|
|
|
}
|
2020-02-29 06:33:26 +00:00
|
|
|
|
2020-02-29 06:47:56 +00:00
|
|
|
unsigned pcs_get_bits_remaining(PrimeCandidateSource *pcs)
|
|
|
|
{
|
|
|
|
return mp_get_nbits(pcs->limit);
|
|
|
|
}
|
|
|
|
|
|
|
|
mp_int *pcs_get_upper_bound(PrimeCandidateSource *pcs)
|
|
|
|
{
|
|
|
|
/* Compute (limit-1) * factor + addend */
|
|
|
|
mp_int *tmp = mp_mul(pcs->limit, pcs->factor);
|
|
|
|
mp_int *bound = mp_add(tmp, pcs->addend);
|
|
|
|
mp_free(tmp);
|
|
|
|
mp_sub_into(bound, bound, pcs->factor);
|
|
|
|
return bound;
|
|
|
|
}
|
|
|
|
|
2020-02-29 06:33:26 +00:00
|
|
|
mp_int **pcs_get_known_prime_factors(PrimeCandidateSource *pcs, size_t *nout)
|
|
|
|
{
|
|
|
|
*nout = pcs->nkps;
|
|
|
|
return pcs->kps;
|
|
|
|
}
|