| Age | Commit message (Collapse) | Author |
|---|
|
I'm going to want a generic "onionskin" type and set of wrappers, and
for that, it will be helpful to isolate the different circuit creation
handshakes. Now the original handshake is in onion_tap.[ch], the
CREATE_FAST handshake is in onion_fast.[ch], and onion.[ch] now
handles the onion queue.
This commit does nothing but move code and adjust header files.
|
|
Here we try to handle curve25519 onion keys from generating them,
loading and storing them, publishing them in our descriptors, putting
them in microdescriptors, and so on.
This commit is untested and probably buggy like whoa
|
|
This patch moves curve25519_keypair_t from src/or/onion_ntor.h to
src/common/crypto_curve25519.h, and adds new functions to generate,
load, and store keypairs.
|
|
Previously, we only used the strong OS entropy source as part of
seeding OpenSSL's RNG. But with curve25519, we'll have occasion to
want to generate some keys using extremely-good entopy, as well as the
means to do so. So let's!
This patch refactors the OS-entropy wrapper into its own
crypto_strongest_rand() function, and makes our new
curve25519_secret_key_generate function try it as appropriate.
|
|
|
|
The ntor handshake--described in proposal 216 and in a paper by
Goldberg, Stebila, and Ustaoglu--gets us much better performance than
our current approach.
|
|
We want to use donna-c64 when we have a GCC with support for
64x64->uint128_t multiplying. If not, we want to use libnacl if we
can, unless it's giving us the unsafe "ref" implementation. And if
that isn't going to work, we'd like to use the
portable-and-safe-but-slow 32-bit "donna" implementation.
We might need more library searching for the correct libnacl,
especially once the next libnacl release is out -- it's likely to have
bunches of better curve25519 implementations.
I also define a set of curve25519 wrapper functions, though it really
shouldn't be necessary.
We should eventually make the -donna*.c files get build with
-fomit-frame-pointer, since that can make a difference.
|
|
There was one place in curve25519-donna-c64 that was relying on
unaligned access and relying on little-endian values. This patch
fixes that.
I've sent Adam a pull request.
|
|
|
|
This is copied from Adam Langley's curve25519-donna package, as
of commit 09427c9cab32075c06c3487aa01628030e1c5ae7.
|
|
I'm going to use this for looking op keys server-side for ntor.
|
|
|
|
This is a customizable extract-and-expand HMAC-KDF for deriving keys.
It derives from RFC5869, which derives its rationale from Krawczyk,
H., "Cryptographic Extraction and Key Derivation: The HKDF Scheme",
Proceedings of CRYPTO 2010, 2010, <http://eprint.iacr.org/2010/264>.
I'm also renaming the existing KDF, now that Tor has two of them.
This is the key derivation scheme specified in ntor.
There are also unit tests.
|
|
|
|
|
|
|
|
Fixes bug #7592; bugfix on 882b389668067a29bb539d0f5bd5cb2f83b93012.
The bug is not present in any released versions of Tor.
|
|
|
|
|
|
|
|
|
|
"error=Unable to launch resolve request" is not a nice thing to tell
the controller. Bugfix on 0.2.0.19-alpha (c11c48fc).
|
|
|
|
RFC1123 suggests that we should handle two-year times, and a full
range of time zones, and other stuff too. We don't.
|
|
Fix for #6113.
Note that the RFC1123 times we generate still all say 'GMT'. I'm
going to suggest this is not worth changing.
|
|
Affects comments only. For ticket 6849.
|
|
|
|
|
|
This one is necessary for sending BEGIN cells with sane flags when
self-testing a directory port. All real entry connections were
getting their ipv{4,6}_traffic_ok flags set from their listeners, and
for begindir entry connections we didn't care, but for directory
self-testing, we had a problem.
Fixes at least one more case of 7493; if there are more lingering
cases of 7493, this might fix them too.
Bug not in any released version of Tor.
|
|
|
|
|
|
Looks like when i was writing the code to set the ipv4_traffic flag on
port_cfg_t, I missed some cases, such as the one where the port was
set from its default value.
Fix for 7493. Bug not in any released Tor.
|
|
|
|
|
|
Previously, I was freaking out about passing an unspec address to
dns_found_answer() on an error, since I was using the address type to
determine whether the error was an error on an ipv4 address lookup or
on an ipv6 address lookup. But now dns_found_answer() has a separate
orig_query_type argument to tell what kind of query it is, so there's
no need to freak out.
|
|
|
|
|
|
|
|
|
|
This is imperfect, since it sends back whatever we would send to
a socks RESOLVE request, when in reality we should send back whatever
was asked for.
|
|
|
|
|
|
|
|
* If there's an IPv4 and an IPv6 address, return both in the resolved
cell.
* Treat all resolve requests as permitting IPv6, since by the spec they're
allowed to, and by the code that won't break anything.
|
|
IPv4-only exits have an implicit "reject [::]/0", which was making
policy_is_reject_star() return 1 for them, making us refuse to do
hostname lookups.
This fix chanes policy_is_reject_star() to ask about which family we meant.
|
|
|
|
We had some old code to send back connected cells for IPv6 addresses,
but it was wrong. Fortunately, it was also unreachable.
|
|
|
|
The code previously detected wildcarding and replaced wildcarded
answers with DNS_STATUS_FAILED_PERMANENT. But that status variable
was no longer used! Remove the status variable, and instead change
the value of 'result' in evdns_callback.
Thank goodness for compiler warnings. In this case,
unused-but-set-variable.
Thanks to Linus for finding this one.
|
|
|
