The streaming interface for AEAD was a bad idea: it's harder to test and
encourages unsafe protocol design (unsafe handling of unauthenticated
data, denial of service amplification...).
Michael Forney [Tue, 19 Nov 2019 20:15:16 +0000 (12:15 -0800)]
Remove unnecessary dependency on 2's complement
Although the bit-representation of signed integer types in C99 is
implementation-defined and can be sign-magnitude, one's complement, or
two's complement[0], the conversion of negative values to an unsigned
integer type is defined to be adding 1 plus the maximum value of the
unsigned type[1].
Since -1 + 0xffffffff + 1 == 0xffffffff, just using u32 here has the
right behavior without relying on the representation of signed integers.
Loup Vaillant [Mon, 18 Nov 2019 21:41:41 +0000 (22:41 +0100)]
Leveraged fe_pow22523 to to simplify fe_invert
The multiplication chain used in those two function is probably optimal,
but it is also kind of black magic, and takes quite a bit of code.
TweetNaCl has a much shorter, much easier to read, much slower addition
chain. I figured maybe a middle ground were possible.
Turns out it's difficult. I couldn't come up with a nice multiplication
chain on my own. But I did notice a relationship between 2^252 - 3 and
2^255 - 23 (the latter is used to invert): they start with the same bit
pattern. More specifically:
2^255 - 23 = (2^252 - 3) * 8 + 3
I can use the same multiplication chain for both function, and just
finish the job for the inversion.
The cost of this patch compared to the ref10 multiplication chain is
five field multiplications, three of which are squaring. The effect on
the benchmark is so small that we don't even notice the difference.
The benefit is 10 meaty lines of code, and a corresponding decrease in
binary size.
Loup Vaillant [Tue, 22 Oct 2019 21:38:15 +0000 (23:38 +0200)]
Fixed Clang warning about Doxygen comments
comments that begin by //< can be Doxygen comments, and Clang with all
warnings doesn't like that.
I originally packed the comment to satisfy my 80 column OCD. By
sacrificing space around the + operator however, we can reclaim that
space and please Clang.
Loup Vaillant [Mon, 21 Oct 2019 12:57:03 +0000 (14:57 +0200)]
Cleaned up the tests/ folder
Just moving files around so it's better organised.
Also changed the vectors.h header a little:
- It now includes inttypes.h and and stddef.h only once.
- There's a note at the top saying where it comes from.
Loup Vaillant [Sat, 19 Oct 2019 23:01:43 +0000 (01:01 +0200)]
Tightened up the release script
- Run tests/test.sh prior to release
- Removed the dist target from the shipped makefile
- Removed the contributor notes from the shipped README
- Don't include files that only serve to generate vectors.h
- Reworded some of README a little bit.
Exposing version numbers in the binary can expose them to attackers.
Without the version number, they have to try the exploit and hope. With
the version number, they may perform a cheap check before they proceed
any further. Better not take the risk.
Furthermore, changing the length of the string may break ABI. This will
happen if a version number (major, minor, or patch) ever reaches 10.
That patch was nice, but it potentially impact security and stability.
Not worth it in the end.
Loup Vaillant [Sat, 19 Oct 2019 13:14:48 +0000 (15:14 +0200)]
Added version number to binaries
Sometimes, we don't have the sources, and we want to check the version
number of the binaries themselves. (For instance when distributing
Monocypher as a library.)
To that end, I've added the global string constant "monocypher_version".
It can be used from the calling program, or scanned directly by tools.
Loup Vaillant [Sat, 19 Oct 2019 12:44:28 +0000 (14:44 +0200)]
Include version in released source files
I realised that determining which Monocypher version was used in a
project was not trivial. We could look at Monocypher's code and deduce
the release, but that's tedious and error prone. So I've made those
versions more explicit:
- Source and header files begin by a comment describing the version.
- The pkg-config file created by `make install` include that version.
- The version number of unreleased code (under git) is "__git__"
- The version number of released code is whatever `git describe --tags`
tells us.
- the "tarball" target in the makefile was changed to the more standard
"dist".
To release a new version, we just add a tag, then call `makefile dist`.
The version of the released source file will appear at a glance, right
there on the first line.
Note: the release process blindly replaces all instances of "__git__" by
the suitable version number. This could be used to version things other
than comments, like string constants.
Loup Vaillant [Wed, 16 Oct 2019 22:14:11 +0000 (00:14 +0200)]
Tidied up sliding windows, minor cosmetic nitpicks
Added `static` to the sliding window functions, reworked those functions
a bit to improve the (internal) API. Simplified the double scalarmult
accordingly.
Added FOR_T macro, for when the index should be a type other than
size_t. Helped remove explicit conversions in Argon2i and sliding
windows. Hopefully this new macro will be obvious to reviewers. I
could have used the regular `for` loop, but it took too much horizontal
space in Argon2i (we use long names there).
Loup Vaillant [Sun, 13 Oct 2019 23:06:43 +0000 (01:06 +0200)]
Updated AUTHORS.md for EdDSA
The EdDSA code is now unrecognisable from what we saw in either SUPERCOP
and TweetNaCl. Some significant pieces are still from ref10 or
TweetNaCl, but the overall structure is different enough that I should
consider myself the primary author...
Loup Vaillant [Sun, 6 Oct 2019 22:45:05 +0000 (00:45 +0200)]
Fused sliding windows and scalar multiplication
At last, we saved some stack. 320 bytes on my machine, which is a bit
disappointing. We may be able to shave off a couple more, but we're
reaching the limit.
Loup Vaillant [Sun, 6 Oct 2019 21:58:38 +0000 (23:58 +0200)]
Incremental left to right sliding windows
The main loop of the scalar multiplication goes one by one, so we can't
have the sliding loop skip indices. By adding a context that keeps
track of the next needed addition (as well as its value), we'll be able
to fuse the two slides and the scalar multiplication together.
Loup Vaillant [Sun, 6 Oct 2019 20:12:42 +0000 (22:12 +0200)]
Slide from left to right
Scalar multiplication goes from left to right (from MSB to
LSB). Computing the sliding windows used to go from *right to left*.
This direction mismatch forced us to keep all the signed digits in
memory, which currently incur a little over 500 bytes of stack overhead.
That overhead is avoidable. Avoiding it will allow Monocypher to fit in
smaller embedded devices.
Right now we just change the direction of the sliding. Interleaving will
come later.
Those are easily visible through the QtCreator IDE intellisense, but
somehow never showed up when compiling at the command line. This should
help silence MSVC warnings as well.
Turns out compilers don't do this naturally, and this leads to
observable slow downs in some cases.
Also noted that we are relying on 2's complement representation (we
already were). We could be more portable by going unsigned, but by this
logic the entire field arithmetic should go unsigned. It's possible,
but it's not trivial. I've kinda tried it in the past, and failed.
Every architecture of interest is 2's complement anyway, so I think this
will be good enough.
Those functions are used for both X25519 and EdDSA. Moving them up one
section makes it easier for user to delete the X-25519 section without
affecting EdDSA.
(Overall, Monocypher should let users delete the code they don't
need. This wasn't an explicit goal initially, but the code naturally
turned out that way. Supporting this use case cost us nothing.)
Made the 3 options (from source, from lib, system wide installation)
clearer, and stated the ability to change compilation flags explicitly.
(Those flags are all standards, but not everyone may know them).
projects / Monocypher.git / log