For an odd n-bit number, we can't find two n-1-bit numbers which
multiplied gives an n-bit number. That's why public key length n must be
an even number.
I have also renamed AreSafePrimes to IsSafePrime since only the first
function argument is considered to be a safe prime according to a safe
prime definition.
Added information about the required minimum bit length of the public
key. Removed the threshold information as we are not sure now if it's
valid. We'll investigate it separately and make sure a proper validation
for threshold is made.
Instead of passing safe prime bit length which is a kind of an
implementation detail, we should pass a public key bit length. Public
key is a Paillier modulus defining plaintext space. This information is
more important than the safe prime value/bit length used under the hood.
According to [DJN 10], the plaintext space is `Z_n`. We had this
information in the `Encrypt` and `EncryptWithR` documentation but
sometimes, when encrypting result of more complex equations, it's easy
to miss the fact the result is out of the allowed range.
Here we have just a safety check making sure that if plaintext is out of
allowed space, we report an error.
We can use `defer waitGroup.Wait()` to make sure it's called regardless
which path we go. This we, we can call `return ...` directly from all
select cases and we don't need named parameters.
It does not longer make sense to have a mutex and cancelled context check
since we have a wait group and channels with buffers with the size equal
the number of workers.
Without the wait group we had to make sure no goroutine tries to write
to the closed channel. Now, channel is closed after all goroutines
completed (either by finding prime or cancelling the work), so there is
no chance someone tries to write to closed channel.
`4` and `120*time.Seconds` were just some magic numbers in the code.
We decided to move them to separate value declarations to make the
code more self-explanatory.
Although the result channel send operation and context cancel are
guarded by the same mutex and context is cancelled by the main thread
when it receives a result message from the channnel, there is absolutely
no guarantee that one goroutine can't write result to the channel after
the first goroutine did the same and before the main thread cancelled
the context. This is the following scenario:
- Worker #1 acquires mutex, writes to the result channel
- Worker #2 acquires mutex, writes to the result channel
- Main thread reads from the result channel, acquires mutex, cancels the
context
Since our result channel (and error channel) had buffer of size 1, the
Worker #2 was hanging indefinitely. Setting the buffer size to the
number of goroutines fixed the problem.
Alternative scenario was:
- Worker #1 acquires mutex, writes to the result channel
- Main thread acquires mutex, reads from the result channel, cancels the
context
- Worker #2 receives cancel notification so it completes without
yielding the result
That's why deadlock was happening only from time to time.
Go 1.7 moved the `golang.org/x/net/context` package into the standard
library as `context`. Code importing `context` is no longer compiling
for Go versions earlier than 1.7. Since 1.7 was released two years ago
and we don't want to sacrifice quality, we decided to drop support for
1.4 and 1.3 and support 1.7+ now.
Initially, we did not wait for all goroutines to finish which was fine
as long as we did not run all tests with `go test` and observe deadlock
in 50% of cases. This is interesting, since deadlock never occurred when
running safe_prime_generator_test.go. Anyway, waiting for all go
routines to finish shouldn't harm the performance a lot and it gives a
guarantee we did not miss anything.
How fast we generate a prime number is mostly a matter of luck. It
varies from miliseconds to seconds and depends how lucky we are with
drawing bytes.
With today's multicore processors, we can execute the process on
multiple cores concurrently, accept the first valid result and cancel
the rest of work. This way, with the same algorithm, we get the result
faster.
I've adapted a Go code for generating random numbers by inserting some
optimisations that will allow us to generate safe primes faster than
with the previous, naive approach.
First of all, having q which can be prime, we first check whether q%3=1.
If that's true, there is no chance p=2q+1 is prime. It lets us to reject
candidate numbers quicker without running an expensive primality tests.
Also, before we run a primality test for q, we may check p=2q+1 against
the primes between 3-53 (We are limited by Go's uint64 range).
If all those conditions are met and we know p is prime, it's enough to
check Pocklington criterion for q instead of running an expensive
primality test for it.
It's now possible to multiply Cypher by an integer.
Paillier is a homomorphic encryption scheme, where an encrypted
plaintext `m` raised to an integer `k` will decrypt to the product of
the plaintext `m` and `k`.
sachaservan