doc: Use canonical spelling of ChaCha20

Spelled with two capital Cs according to Daniel J. Bernstein. "ChaCha,
a variant of Salsa20." Workshop Record of SASC 2008: The State of the
Art of Stream Ciphers.

Advertise public key cryptography in the manual

Followup on the modifications of the README: if users can't make the
connection between public key cryptography and key exchange there, they
won't make it either when reading the manual (which by the way is
automatically copied to the website).

Fixed local variable shadowing

In crypto_x25519_inverse(), line 2949 and 2953, we use the ZERO macro in
a context where the enclosing scope already defines the varible `i`.

Turns out ZERO defines `i` for internal use in an enclosed scope. This
trigger a warning in some compilers about variable shadowing: declaring
a local variable with the same name as an enclosing local variable. This
warning is especially annoying when combined with -Werror.

To prevent this, the macros COPY and ZERO have been modified so they use
a variable name that is unlikely to be used anywhere else (`i__`).

Advertise Monocypher's features more clearly

For the second time, I've stumbled upon a user that believed Monocypher
did not support public key cryptography, despite the presence of a
fairly high-level key exchange API.

Looking at the README and website, I noticed that while key exchange is
fairly well publicised, "public key cryptography" is not.  I suspect
many users simply don't know that key exchange is a valid way to do
public key cryptography.  In hindsihght, we should not expected them to.

Let's not dwell on how many potential users we may have lost to this
oversight.  Hopefully, writing "Public key cryptography" directly will
help people notice.

Define fe_invert() in terms of invsqrt()

Pros:
- The code is a couple lines shorter.
- Stack usage may be lowered a tiny little bit (we saved two temporary
  field elements).

Cons:
- Inversion is one field multiplication slower.

Note that fully optimised inversion can be 6 field multiplications
faster than the current version. It would cost quite a bit of code
though (we'd need a dedicated addition chain).

Merge pull request #211 from fscoto/master+doc-incremental

doc: Compute secret/public key in some examples

Install advanced man pages

Note that deprecated man pages are omitted.
I believe we should not clutter man pages with them.
Advanced functions however should have their place in the user manual.

Clarified wording in incremental signatures man page

Thanks Fabio for suggestions on this patch.
(Any error is still mine, though.)

doc: Compute secret/public key in some examples

crypto_sign_init_first_pass(3monocypher) gets two initializations of sk
and pk.
They're long-lived keys, but at least now it's possible to run the
example without wondering why nothing works.

Simplified crypto_x25519_dirty_small() a tiny bit

To give the same results as crypto_x25519_dirty_fast(), we originally
multiplied the cofactor by 5 before we multiplied it by L. I noticed
however that this multiplication by 5 could be baked in the base point
itself, and simplifies the computation a little bit.

This also saves a single MUL instruction.

Expand Blake2b tests to full length keys and hashes

Typo

Test many combinations of input lengths for blake2b

Use official Blake2b test vectors

Should have done this years ago. The test vectors we had were pretty
good, but the official ones are, well, official.

Note that we kept a good deal of our own vectors: while the official
test vectors tested all possible key sizes, they did not test all
possible hash sizes or all possible key sizes.

Added tests vectors for Blake2b

- We tested with no key, and an empty message.
- We tested with no key, and a non-empty message.
- We tested with a key, and a non-empty message.
- We did *not* test with a key and an empty message.

Well, now we do. Libsodium seems to agree with us. Phew.

Speed benchmark: fixed buffer overflow

Argon2i: remove useless intermediate block

Tests suite: fixed C++ compatibility

Updated CHANGELOG

Merge pull request #203 from fscoto/master+chacha20-doc

crypto_ietf_chacha20: note nonce overflow handling

crypto_ietf_chacha20: note nonce overflow handling

IETF ChaCha20 has a 32-bit counter.
This means a practical limit of 256 GiB of data for each nonce.
Additionally, IETF QUIC seems to require being able to handle
0xffffffff (I-D.draft-ietf-quic-tls-33 § 5.4.4),
thus getting very close to the overflow,
though not triggering it.

Unlike libsodium and other libraries, we do not have the option to
panic and take down whatever process is running the code and triggering
the overflow condition because Monocypher is neither allowed to use the C
standard library nor allowed to invoke undefined behavior to cause a
crash;
the applicable RFC provides no guidance what to do in this case, either.

Therefore, staying within the (nonce, counter) limits is necessarily
application responsibility;
it is an invariant that, when voided, Monocypher is allowed to do
anything,
similar to the non-guarantee we make for the crypto_blake2b family
and the crypto_argon2i family.

While already here, fix the wrong function prototype in the synopsis.

Defined IETF Chacha20 in terms of DJB Chacha20

- It's simpler.
- It makes clear that only the initialisation differ.
- It allows us to inline chacha20_core() and gain a few more lines.

Tests: fixed array size mismatch warning

Fix dead store

Fixes #201

Removed spurious comment

Restricted TIS-CI to the most different platforms

We don't care about floating points & such, so we only need to select
a few platforms among all proposed.  This change cuts the number of
platforms by half.

Tweaked EdDSA signature pre-computed table

Moved from a single 5-bit comb to a dual 4-bit comb.  The size of the
comb is unchanged, but we perform fewer operations.

Before:
- 50 doublings, 51 additions (101 operations)
- 51 16-way constant time lookups
After:
- 30 doublings, 62 additions (92 operations)
- 62 8-way constant time lookups

Note: I hoped for a 6% speedup, barely observed 3.5%. I suspect this is
because additions, even from pre-computed tables, cost a little more
than doublings.

Note: we could save an additional addition by assuming scalars modulo L
all fit in 252 bits.  They do not, but if we pick one at random, they
will in practice (with 2^-128 probability of being wrong, i.e. never).

This would work well in EdDSA, where the scalar is a hash of the private
key.  Finding a private key that makes the scalar overflow 252 bits is
about as hard as breaking a 128-bit key, which we can safely assume will
never happen by accident.

However, this scalar multiplication is also used in the dirty public key
generation, which we use to create hidden X25519 keys with Elligator
(from Edwards, because it's twice as fast as the Montgomery ladder).
Here, users provide the scalar directly. Overflowing 252 bits *can*
happen by accident, if users shoot themselves in the foot with a
non-random scalar.

The risk is small, but a measly 1% performance is not worth leaving
ourselves open to subtle corner cases like that.

Faster reduction modulo L

Replaced TweetNaCl's code by Barrett reduction.

- mod_l(), reduce(), and mul_add() use less stack.
- mod_l(), reduce(), and mul_add() are now much faster.
- Signature generation is noticeably faster (~7% on my Skylake laptop).
- Now I understand all the code. No more black boxes.

The change cost a total of 8 lines of code.

Added speed benchmark for ed25519-donna

s/Monocypher/Libsodium in a string

Update CHANGELOG for next version

Remove TIS-CI from the tarball

More uniform TIS-CI file names

Merge pull request #200 from fscoto/master+fix-elligator-comment-typo

elligator.py: fix comment typo

Typos

elligator.py: fix comment typo

Streamlined TIS-CI dirty X25519 test

Moved fe constant with the others

Added test vectors from Kleshni

Fixes #181

The MON-01-004 issue from Cure53's audit noted that Monocypher did not
compare to <https://github.com/Kleshni/Elligator-2>, which I didn't know
of at the time.  Some test vectors were added back then, but full
interoperability was not yet ascertained.  (Moreover, I though I'd added
vectors for the reverse map, and somehow didn't. This is now fixed.)

Now I have been able to generate decoding (direct map) test vectors from
Kleshni's implementation, that Monocypher matches perfectly.  For the
inverse map however, I was not so lucky: Monocypher and Kleshni disagree
on quite a few points, including those used in Kleshni's test vectors.

Some investigation revealed that currently, Kleshni's encoding (inverse
map) is not reliable.  In some cases, the round trip fails to yield the
same point we started with (and it's not just a matter of chopping off
the most significant bit).

However, Monocypher and Kleshni *do* agree on some points, which I have
added (and *checked* I have added) to the list of test vectors.  There's
just one divergence left: Monocypher fails to encode the zero point,
which is a departure from the standard (we're supposed to output the
zero representative instead).

Documented 2^255-19 carry propagation

Fixes #185

Carry propagation is now justified, in a way that I can personally vouch
for (I used to rely on SUPERCOP's ref10 code and proofs).

The use of arithmetic right shifts is also documented, and a workaround
has been devised in case someone somewhere uses a platforms that does
not perform sign extension. (That will never happen.)

Fixed assumption in 2^255-19 carry propagation

Careful re-examination of the carry propagation code revealed that
SUPERCOP's invariants for fe_tobytes() were not respected: there is a
possibility that the inputs slightly outrange the set of input for which
SUPERCOP's original proof was intended.

This happens in invsqrt(), used for EdDSA verification And Elligator,
and the reverse map of Elligator.  X25519 is unaffected.

Note that we were unable to produce a set of input that actually
triggers this range overflow.  Moreover, careful mathematical analysis
(and tests with SAGE) showed that fe_tobytes() is actually much more
tolerant than SUPERCOP's proof let on.  As far as I can tell, this
slight overflow cannot trigger any observable bug.

Still, I figured it would be a good idea to abide those invariants
anyway, if only to facilitate future audits.  To this end, I made sure
the inputs of fe_tobytes() came directly from either multiplications
(which perform a carry propagation), or constants (where carry
propagation has been pre-computed).

TIS-CI: ensure results are correct

Lighter TIS-CI tests

Overhauled TIS-CI test suite

Tests: fixed tweak coverage for Elligator.

Shifting the index by 6 caused a reuse of one bit, leading to 4
different configurations instead of 8.
Shifting by 5 means we are using the 3 least significant bits of the
index, as was always intended.

Fixed tis-ci.c declarations

Removed non-standard empty array

Manual: fixed old HChacha20 function name

Manual: function prototype typo

Tests: all messages to standard ouput

Never ignore test failures

Added vector based Chacha20 tests

Re-ignore tests/vectors.h

simplified TEST macro

We'll no longer need the entry points, TIS-CI will have dedicated tests

Reworked test vectors header format

- Removed the header from git (we will no longer need it)
- Replaced the direct arrays by character strings in hexadecimal format.

That last one is an attempt to make those vectors more readable and
smaller (vectors.h is the biggest source of bloat in the tarballs).

Merge pull request #195 from fscoto/master+doc-malleability

doc: clarify signature malleability in crypto_sign

doc: clarify signature malleability in crypto_sign

Fixes #189; see the discussion there for details.

Dedicated test suite for TIS-CI

TIS-CI needs a dedicated test suite, different from the regular one.  So
I'm following my Chief Testing Officer's advice, and stole his work like
I should have from the very beginning.

We'll need to refine this, but this should be a good first step.

Merge pull request #191 from fscoto/master+doc-malleability

HISTORY: note 2.0.5 rejecting modified signatures

Merge pull request #192 from fscoto/master+argon2i-oops-the-params-also-matter

argon2i: Note that all parameters influence output

argon2i: Note that all parameters influence output

Sparked by #190.

HISTORY: note 2.0.5 rejecting modified signatures

Change introduced in 974e55d21c1fac7a2e21f91cb7174601b653180a and
24f4be7acc3ec7ff613715a7a97597e587f6d6d8.

The actual reasons to introduce this were actually performance-related.

Sparked by #189.

documented make install USE_ED25519=true

Fixed copy in man2html.sh

Poly1305 carry propagation now uses loops

Mostly for consistency with 25519 arithmetic.
Also slightly reduces binary size in some cases, most notably -Os.

Small carry simplification

More readable Blake2b unrolled loop

Fixed compiler warning

Fixes #187

Note: w should remain a signed integer, so w-1 is correctly compared in
the FOR_T loop.

No longer ignore tests/vectors.h (for TIS-CI)

Fixed tis.config (3)

Fixed tis.config (2)

Fixed tis.config

Added TIS-CI support

Prepared entry points for TIS-CI

Separated basic/advanced functions in different folders

Addresses MON-01-005
Fixes #182

Better low/high level separation in the header.

Partially addreses MON-01-005.  #182

Also added various warnings in comments.

Also pretend the min number of Argon2i iterations passes is 3.
It's not true, but any less would not be secure.

Argon2i hash is now allowed to overlap with the work area

Fixes #183

Almost all of Monocypher allows arguments to overlap. Users may come to
expect it, and misuse those who don't allow such an overlap. (Chacha20
and AEAD are an exception, but (i) portability concerns prevents us to
allow it properly, and (ii) disallowed overlaps tend to trigger visible
corruptions immediately.)

Before, having the hash coincide with the working area meant the output
was always zero.  All passwords have the same hash.  Therefore all
passwords are correct.  Oops.  For the record, I made the mistake, and
caught the bug only days later, by pure luck.

Now overlap is allowed, and gives the right result. Note that the work
area is still wiped.  The wipe just happens *before* the final hash is
computed.

Merge pull request #184 from fscoto/master+mon-01-001

intro: macOS, illumos and Solaris have arc4random_buf(3)

Fix #180

intro: macOS, illumos and Solaris have arc4random_buf(3)

Better test for crypto_x25519_inverse()

Removed redundant all zero test vector

Added Kleshni/Elligator-2 test vectors

An auditor recently told me about the following repository on GitHub:

  https://github.com/Kleshni/Elligator-2/

I was able to steal a couple test vectors from them.  Not all of them
unfortunately:

- Some representative exceed 2^254, and Monocypher do not decode
  negative representatives.  Instead, it assumes it has a positive
  representative, and clears the two most significant bits before
  decoding.

- It is not clear yet what encoding does, and some points in the (few)
  test vectors have their most significant bit set. Monocypher ignores
  the most significant bit of curve point, basically assumes they are
  all below 2^255 - 19.  Adding those points will require tweaking
  similar to the tweaking applied to the Hash to Curve RFC draft test
  vectors.

Added extern "C" to optional & deprecated files

Adjusted changelog date

Updated changelog

Optimised key loading in Blake2b

The idea is to avoid the slow loading code in the internal
blake2b_update() function, and avoid the overhead of calling
crypto_blake2b_update().

It's a micro-optimisation that in principle shouldn't matter that much,
but it might help a bit if we repeatedly hash small messages with a key,
as can happen in authenticated key exchanges like Monokex.

Removed #define from vectors.h

Also reduced the size of vectors.h by removing indirections and printing
numbers in decimal form. Hopefully this will make the tarball a little
smaller.

Fixed various compiler warnings

Fixes #179

Merge pull request #178 from fscoto/master+fix-includes

doc: Fix .In for optional code

doc: Fix crypto_ed25519_public_key function name

doc: Fix .In for optional code

README: Monocypher is not compatible with NaCl

Fixes #177

This removes the suggestion that we can replace Monocypher with NaCl.
We cannot, only Libsodium is compatible.

Cosmetic. compact grouping of vtables

Turned ALIGN into a function

Merge pull request #173 from fscoto/master+reproball

Make tarball generation reproducible

dist.sh: Make tarball reproducible

Make Elligator test vector gen deterministic

This paves the way for reproducible tarballs.
Since the test vectors must be generated for a complete tarball,
these must agree everywhere.

The lack of actual randomness is harmless because these are test
vectors, not actual usages of Elligator.

More readable Blake2 round function

Fixed (NULL + 0) undefined behaviour

It appears that arithmetic on NULL pointers is undefined, even when we
just add zero.

Monocypher generally allows input buffers to be NULL pointers if their
length is zero.  This is because we never dereference those pointers in
this case.  Likewise, we should not perform any arithmetic on them.

The fix is to return immediately when the input buffer length is zero.

Merge pull request #171 from stevefan1999-personal/patch-1

Add extern C if C++ presents