Also, use it to generate test vectors, and add those test vectors
to test_crypto.c
This is based on ed25519.py from the ed25519 webpage; the kludgy hacks
are my own.
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?)
This is another case where DJB likes sticking the whole signature
prepended to the message, and I don't think that's the hottest idea.
The unit tests still pass.
This reduces the likelihood that I have made any exploitable errors
in the encoding/decoding.
This commit also imports the trunnel runtime source into Tor.
Uses libscrypt when found; otherwise, we don't have scrypt and we
only support openpgp rfc2440 s2k hashing, or pbkdf2.
Includes documentation and unit tests; coverage around 95%. Remaining
uncovered code is sanity-checks that shouldn't be reachable fwict.
Since address.c is the first file to get compiled, let's have it use
a little judicious c99 in order to catch broken compilers that
somehow make it past our autoconf tests.
When DisableNetwork is set, do not launch pluggable transport plugins,
and if any are running already, terminate the existing instances.
Resolves ticket 13213.
Allow clients to use optimistic data when connecting to a hidden service,
which should cut out the initial round-trip for client-side programs
including Tor Browser.
(Now that Tor 0.2.2.x is obsolete, all hidden services should support
server-side optimistic data.)
See proposal 181 for details. Implements ticket 13211.
Clients are now willing to send optimistic circuit data (before they
receive a 'connected' cell) to relays of any version. We used to
only do it for relays running 0.2.3.1-alpha or later, but now all
relays are new enough.
Resolves ticket 13153.
Return an error when the second or later arguments of the
"setevents" controller command are invalid events. Previously we
would return success while silently skipping invalid events.
Fixes bug 13205; bugfix on 0.2.3.2-alpha. Reported by "fpxnns".
Stop modifying the value of our DirReqStatistics torrc option just
because we're not a bridge or relay. This bug was causing Tor
Browser users to write "DirReqStatistics 0" in their torrc files
as if they had chosen to change the config.
Fixes bug 4244; bugfix on 0.2.3.1-alpha.
Clients now send the correct address for their chosen rendezvous point
when trying to access a hidden service. They used to send the wrong
address, which would still work some of the time because they also
sent the identity digest of the rendezvous point, and if the hidden
service happened to try connecting to the rendezvous point from a relay
that already had a connection open to it, the relay would reuse that
connection. Now connections to hidden services should be more robust
and faster. Also, this bug meant that clients were leaking to the hidden
service whether they were on a little-endian (common) or big-endian (rare)
system, which for some users might have reduced their anonymity.
Fixes bug 13151; bugfix on 0.2.1.5-alpha.
These wrappers went into place when the default type for our unit
test functions changed from "void fn(void)" to "void fn(void *arg)".
To generate this patch, I did the same hokey-pokey as before with
replacing all operators used as macro arguments, then I ran a
coccinelle script, then I ran perl script to fix up everything that
used legacy_test_helper, then I manually removed the
legacy_test_helper functions, then I ran a final perl script to put
the operators back how they were.
==============================
#!/usr/bin/perl -w -i -p
s/==,/_X_EQ_,/g;
s/!=,/_X_NE_,/g;
s/<,/_X_LT_,/g;
s/>,/_X_GT_,/g;
s/>=,/_X_GEQ_,/g;
s/<=,/_X_LEQ_,/g;
--------------------
@@
identifier func =~ "test_.*$";
statement S, S2;
@@
static void func (
-void
+void *arg
)
{
... when != S2
+(void) arg;
S
...
}
--------------------
#!/usr/bin/perl -w -i -p
s/, *legacy_test_helper, *([^,]+), *\&legacy_setup, *([^\}]+) *}/, $2, $1, NULL, NULL }/g;
--------------------
#!/usr/bin/perl -w -i -p
s/_X_NEQ_/!=/g;
s/_X_NE_/!=/g;
s/_X_EQ_/==/g;
s/_X_GT_/>/g;
s/_X_LT_/</g;
s/_X_GEQ_/>=/g;
s/_X_LEQ_/<=/g;
--------------------
"At this point in the code, msg has been set to a string
constant. But the tor code checks that msg is not NULL, and the
redundant NULL check confuses the analyser[...] To avoid this
spurious warning, the patch initialises msg to NULL."
Patch from teor. another part of 13157.
"The NULL pointer warnings on the return value of
tor_addr_to_in6_addr32() are incorrect. But clang can't work this
out itself due to limited analysis depth. To teach the analyser that
the return value is safe to dereference, I applied tor_assert to the
return value."
Patch from teor. Part of 13157.
Tor Browser includes several ClientTransportPlugin lines in its
torrc-defaults file, leading every Tor Browser user who looks at her
logs to see these notices and wonder if they're dangerous.
Resolves bug 13124; bugfix on 0.2.5.3-alpha.
Technically, we're not allowed to take the address of a member can't
exist relative to the null pointer. That makes me wonder how any sane
compliant system implements the offsetof macro, but let's let sleeping
balrogs lie.
Fixes 13096; patch on 0.1.1.9-alpha; patch from "teor", who was using
clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv
(And replay them once we know our first real logs.)
This is an implementation for issue 6938. It solves the problem of
early log mesages not getting sent to log files, but not the issue of
early log messages not getting sent to controllers.
This fixes bug 13102 (not on any released Tor) where using the
standard SSIZE_MAX name broke mingw64, and we didn't realize.
I did this with
perl -i -pe 's/SIZE_T_MAX/SIZE_MAX/' src/*/*.[ch] src/*/*/*.[ch]
This implements the meat of #12899. This commit should simply remove the
parts of Tor dirauths used to check whether a relay was supposed to be
named or not, it doesn't yet convert to a new mechanism for
reject/invalid/baddir/badexiting relays.
Back in 078d6bcd, we added an event number 0x20, but we didn't make
the event_mask field big enough to compensate.
Patch by "teor". Fixes 13085; bugfix on 0.2.5.1-alpha.
This function never returns non-null, but its usage doesn't reflect
that. Let's make it explicit. This will be mostly overridden by later
commits, so no changes file here.
This is in preparation for a big patch series removing the entire Naming
system from Tor. In its wake, the approved-routers file is being
deprecated, and a replacement option to allow only pre-approved routers
is not being implemented.
Otherwise, when we're out of input *and* finalizing, we might report
TOR_ZLIB_OK erroneously and not finalize the buffer.
(I don't believe this can happen in practice, with our code today:
write_to_buf_zlib ensures that we are never trying to write into a
completely empty buffer, and zlib says "Z_OK" if you give it even
one byte to write into.)
Fixes bug 11824; bugfix on 0.1.1.23 (06e09cdd47).
torrc.minimal is now the one that should change as infrequently as
possible. To schedule an change to go into it eventually, make your
change to torrc.minimal.in-sample.
torrc.sample is now the volatile one: we can change it to our hearts'
content.
Closes ticket #11144
This implements a feature from bug 13000. Instead of starting a bwauth
run with this wrong idea about their bw, relays should do the self-test
and then get measured.
When a tor relay starts up and has no historical information about its
bandwidth capability, it uploads a descriptor with a bw estimate of 0.
It then starts its bw selftest, but has to wait 20 minutes to upload the
next descriptor due to the MAX_BANDWIDTH_CHANGE_FREQ delay. This change
should mean that on average, relays start seeing meaningful traffic a
little quicker, since they will have a higher chance to appear in the
consensus with a nonzero bw.
Patch by Roger, changes file and comment by Sebastian.
We're calling mallocfn() and reallocfn() in the HT_GENERATE macro
with the result of a product. But that makes any sane analyzer
worry about overflow.
This patch keeps HT_GENERATE having its old semantics, since we
aren't the only project using ht.h. Instead, define a HT_GENERATE2
that takes a reallocarrayfn.
Most of these are in somewhat non-obvious code where it is probably
a good idea to initialize variables and add extra assertions anyway.
Closes 13036. Patches from "teor".
