Originally, MKCRYPTO was introduced because the United States
classified cryptography as a munition and restricted its export. The
export controls were substantially relaxed fifteen years ago, and are
essentially irrelevant for software with published source code.
In the intervening time, nobody bothered to remove the option after
its motivation -- the US export restriction -- was eliminated. I'm
not aware of any other operating system that has a similar option; I
expect it is mainly out of apathy for churn that we still have it.
Today, cryptography is an essential part of modern computing -- you
can't use the internet responsibly without cryptography.
The position of the TNF board of directors is that TNF makes no
representation that MKCRYPTO=no satisfies any country's cryptography
regulations.
My personal position is that the availability of cryptography is a
basic human right; that any local laws restricting it to a privileged
few are fundamentally immoral; and that it is wrong for developers to
spend effort crippling cryptography to work around such laws.
As proposed on tech-crypto, tech-security, and tech-userlevel to no
objections:
https://mail-index.netbsd.org/tech-crypto/2017/05/06/msg000719.htmlhttps://mail-index.netbsd.org/tech-security/2017/05/06/msg000928.htmlhttps://mail-index.netbsd.org/tech-userlevel/2017/05/06/msg010547.html
P.S. Reviewing all the uses of MKCRYPTO in src revealed a lot of
*bad* crypto that was conditional on it, e.g. DES in telnet... That
should probably be removed too, but on the grounds that it is bad,
not on the grounds that it is (nominally) crypto.
false positives for products of primes larger than 2^16. For example,
before this commit:
$ /usr/games/primes 4295360521 4295360522
4295360521
but
$ /usr/games/factor 4295360521
4295360521: 65539 65539
or
$ /usr/games/primes 3825123056546413049 3825123056546413050
3825123056546413049
yet
$ /usr/games/factor 3825123056546413049
3825123056546413049: 165479 23115459100831
or
$ /usr/games/primes 18446744073709551577
18446744073709551577
although
$ /usr/games/factor 18446744073709551577
18446744073709551577: 139646831 132095686967
Incidentally, the above examples show the smallest and largest cases that
were erroneously stated as prime in the range 2^32 .. 3825123056546413049
.. 2^64; the primes(6) program now stops at 3825123056546413050 as
primality tests on larger integers would be by brute force factorization.
In addition, special to the NetBSD version:
. for -d option, skip first difference when start is >65537 as it is incorrect
. corrected usage to mention both the existing -d as well as the new -h option
For original FreeBSD commit message by Colin Percival, see:
http://svnweb.freebsd.org/base?view=revision&revision=272166
by reference, and changes the value behind the pointer under some
circumstances (basically if it finds more than 2 different factors).
It also calls itself if it finds a factor which is not considered prime
(by openssl's miller-rabin check) and uses the call argument afterwards.
This doesn't work -- we need to copy the argument into its own storage.
-Modify the code to do the "rho" algorithm as was initially announced.
It takes somewhat longer in rare cases, but still works in cases where
the "p-1" algorithm is unusable. This might fix PR misc/43192
by Luiz Henrique de Figueiredo.
-Add some optional debug support, minor cleanup.
could be overrun if its last entry (65537) was a factor of the input
(this does not affect PR misc/43192 -- the factors are much larger
here: 7742394596501*159455563099482401)
algorithm; fixes "factor 2147483647111311". Correct comment;
algorithm is Pollard p-1, not Pollard rho. Increase base if p-1
algorithm reaches 1; fixes "factor 99999999999991". Testcases from
David A Bagley <bagleyd@tux.org>.
was prime to still called the Pollard Rho function when it didn't have
to. Problem report by Nathan Williams.
Unfortunately this one can't be picked up by a simple regression test
since the broken way still produced the correct output, but just took
far longer...
This merges in all such remaining changes from the Linux port of the
NetBSD games, except in hunt (where substantial changes from OpenBSD
need to be looked at).
Some such changes were previously covered in PRs bin/6041, bin/6146,
bin/6148, bin/6150, bin/6151, bin/6580, bin/6660, bin/7993, bin/7994,
bin/8039, bin/8057 and bin/8093.
christos