Fabio Scotoni [Tue, 24 Mar 2020 07:41:48 +0000 (08:41 +0100)]
doc: contributory behavior may be required sometimes
While already there, hoist the explanation about contributory behavior
from RETURN VALUES to the main DESCRIPTION section.
The only reason it was in RETURN VALUES is because of historical
reasons; we used to justify why the return value was deprecated there,
so the position of the explanation made sense before removal of the
return value.
Loup Vaillant [Wed, 18 Mar 2020 14:40:04 +0000 (15:40 +0100)]
Elligator: take cofactor from secret key instead of tweak
This allows the simplification of the implementation of higher level
interfaces.
The idea is, only the scalar and cofactor have any influence over
whether the inverse map succeeds or fail. This means that when it fails,
the padding & sign have not be used at all, and can be "reused" to
generate another random seed.
In practice, this means we can use Chacha20 or Blake2, or any hash that
outputs 64 random bytes from 32 random bytes, use 32 bytes to make an
attempt, then use the *other* 32 bytes to either generate more random
bytes (if we failed), or to use the tweak (if we succeed).
The tweak has also been modified to simplify the implementation. The
sign bit is now the least significant bit, and the padding bits are the
most significant bits. The computational savings are negligible, but
this allows neat micro-simplifications.
Loup Vaillant [Wed, 18 Mar 2020 11:27:31 +0000 (12:27 +0100)]
Added easy interface for Elligator
Note a small problem in the implementation: we are reusing one byte for
both the tweak and the next random seed. This makes them *not*
independent, and a possible source of vulnerability.
In practice, this is only a problem for the 3 bits comprising the
cofactor, since the sign and the padding do not play a role in deciding
whether the mapping fails or succeeds.
TODO: take the cofactor from the clamped bits of the scalar, instead of
the tweak. This will ensure proper independence, while keeping the high
level code simple and maximally efficient.
Fabio Scotoni [Mon, 2 Mar 2020 07:36:52 +0000 (08:36 +0100)]
extract_examples.sh: warning cleanup
1. Remove now-unused random_bytes().
2. "warning: empty struct has size 0 in C, size 1 in C++ [-Wc++-compat]"
"warning: empty struct is a GNU extension [-Wgnu-empty-struct]"
clang -Weverything
Fabio Scotoni [Mon, 2 Mar 2020 06:57:22 +0000 (07:57 +0100)]
crypto_chacha20 example overhaul
1. Randomize keys and nonces.
2. Minor alignment fix in second example.
3. Make i unsigned to avoid clang warning about 500-(i-64) changing
signedness with -Weverything.
4. Initialize ctr to 0.
5. Fix obviously wrong encryption by jumping around example
(repeating ctr issue [!], wrong function used in the example).
Fabio Scotoni [Mon, 2 Mar 2020 06:34:14 +0000 (07:34 +0100)]
crypto_argon2i example overhaul
1. The common type for a password is char*; use a cast instead.
C11, para. 6.5(7) suggests this will be largely okay.
2. Wipe the password on failure.
3. Initialize the password size while there.
Does not use strlen(3) to avoid extra stdlib functions.
4. Branch on allocation failure.
Loup Vaillant [Wed, 26 Feb 2020 21:14:57 +0000 (22:14 +0100)]
Replaced fast mappings by even better ones
Turned out there were much simpler ways to compute the mapping, thanks
to the fact that when the prime p is congruent to 5 modulo 8, we have
this nice equality:
x^((p-5)/8) = sqrt(1/x) if x is square,
x^((p-5)/8) = sqrt(sqrt(-1)/x) otherwise
The code was kindly given by Andrew Moon, who got the original trick
from Mike Hamburg.
Fabio Scotoni [Tue, 25 Feb 2020 08:53:24 +0000 (09:53 +0100)]
Examples: const correctness
It's unfortunate that we can't both tell users to wipe keys and
illustrate which arguments are inputs and which ones are outputs
at the same time, but that's just how it is.
Loup Vaillant [Fri, 21 Feb 2020 22:17:29 +0000 (23:17 +0100)]
Elligator script: use x25519_pk test vectors
We're now reading the `x25519_pk.all.vec` generated by Libsodium in
`x25519.c`, to make sure scalarmult is correctly implemented in the
Python script.
While we're at it, we also use them to generate Elligator 2 vectors.
Any addition to the X25519 public key generation will automatically
benefit Elligator 2 as well
TODO: update the makefile to make sure the vectors are generated before
we run `elligator.py`