| Age | Commit message (Collapse) | Author |
|---|
|
Only some very ancient distributions don't ship with Libevent 2 anymore,
even the oldest supported Ubuntu LTS version has it. This allows us to
get rid of a lot of compat code.
|
|
There were some conflicts here, and some breakage to fix concerning
library link order in newer targets.
|
|
We know there are overflows in curve25519-donna-c32, so we'll have
to have that one be fwrapv.
Only apply the asan, ubsan, and trapv options to the code that does
not need to run in constant time. Those options introduce branches
to the code they instrument.
(These introduced branches should never actually be taken, so it
might _still_ be constant time after all, but branch predictors are
complicated enough that I'm not really confident here. Let's aim for
safety.)
Closes 17983.
|
|
|
|
|
|
|
|
Imported from here: https://github.com/wahern/timeout
Imported as of upstream e5a9e8bfaa9c631bdc54002181795931b65bdc1a.
All sources unmodified.
|
|
|
|
This is where things get tor specific. It's just replacing stdint.h
and memset_s with the tor compat code so going back is trivial...
|
|
|
|
Integrate ed25519-donna into the build process, and provide an
interface that matches the `ref10` code. Apart from the blinding and
Curve25519 key conversion, this functions as a drop-in replacement for
ref10 (verified by modifying crypto_ed25519.c).
Tests pass, and the benchmarks claim it is quite a bit faster, however
actually using the code requires additional integration work.
|
|
|
|
This is taken verbatim from openssh 6.8p1, which appears to have
lightly tweaked it from the openbsd version.
|
|
|
|
|
|
This implementation allows somebody to add a blinding factor to a
secret key, and a corresponding blinding factor to the public key.
Robert Ransom came up with this idea, I believe. Nick Hopper proved a
scheme like this secure. The bugs are my own.
|
|
For proposal 228, we need to cross-certify our identity with our
curve25519 key, so that we can prove at descriptor-generation time
that we own that key. But how can we sign something with a key that
is only for doing Diffie-Hellman? By converting it to the
corresponding ed25519 point.
See the ALL-CAPS warning in the documentation. According to djb
(IIUC), it is safe to use these keys in the ways that ntor and prop228
are using them, but it might not be safe if we start providing crazy
oracle access.
(Unit tests included. What kind of a monster do you take me for?)
|
|
Taken from earlier ed25519 branch based on floodyberry's
ed25519-donna. Tweaked so that it applies to ref10 instead.
|
|
|
|
|
|
There are as many divergent implementations of sys/queue.h as there
are operating systems shipping it, it would seem. They have some code
in common, but have drifted apart, and have added other stuff named
differently. So I'm taking a relatively sane one, and hoping for the
best.
I'm taking OpenBSD's in particular because of the lack of external
dependencies, the presence of a CIRCLEQ (we could use one of those in
places), and the liberal licensing terms.
I'm naming the file tor_queue.h, since historically we've run into
trouble having headers with the same names as system headers (log.h,
for example.)
|
|
|
|
|
|
The rationale for treating these files differently is that we should
be checking upstream for changes as applicable, and merging changes
upstream as warranted.
|
