| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Looks like Roger's debugging code wanted to take a tour of the world
outside his sandbox.
This reverts part of commit 19d37202362c0298ae2f3954b0065ccfcef0dbda.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes bug 7935. Reported by 'oftc_must_be_destroyed'.
|
|
Also add in the random nonce generation.
|
|
|
|
In general, if we tried to use a circ for a stream, but then decided to place
that stream on a different circuit, we need to probe the original circuit
before deciding it was a "success".
We also need to do the same for cannibalized circuits that go unused.
|
|
Fix cannibalize, rend circ and intro circ timeout handling.
|
|
Makes bug 7869 more easily fixable if we ever choose to do so.
|
|
|
|
|
|
|
|
Conflicts:
src/or/cpuworker.c
src/or/or.h
src/test/bench.c
|
|
|
|
|
|
This should make the intent more explicit. Probably needless, though.
|
|
|
|
|
|
|
|
|
|
Before I started coding ntor in C, I did another one in Python.
Turns out, they interoperate just fine.
|
|
|
|
This now matches upstream at version 59a896970a1ad0a6cd7d0.
(Adam took my patches.)
|
|
|
|
This lets us give it compiler flags differing from the rest of
libor-crypto.a
|
|
|
|
"works for me"
|
|
|
|
We want to sanity-check our own create cells carefully, and other
people's loosely.
|
|
|
|
|
|
|
|
The unit of work sent to a cpuworker is now a create_cell_t; its
response is now a created_cell_t. Several of the things that call or
get called by this chain of logic now take create_cell_t or
created_cell_t too.
Since all cpuworkers are forked or spawned by Tor, they don't need a
stable wire protocol, so we can just send structs. This saves us some
insanity, and helps p
|
|
As elsewhere, it makes sense when adding or extending a cell type to
actually make the code to parse it into a separate tested function.
This commit doesn't actually make anything use these new functions;
that's for a later commit.
|
|
The handshake_digest field was never meaningfully a digest *of* the
handshake, but rather is a digest *from* the handshake that we exapted
to prevent replays of ESTABLISH_INTRO cells. The ntor handshake will
generate it as more key material rather than taking it from any part
of the circuit handshake reply..
|
|
The three handshake types are now accessed from a unified interface;
their state is abstracted from the rest of the cpath state, and so on.
|
|
|
|
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.
|
