| Commit message (Collapse) | Author | Age |
... | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Our old warn_nonlocal_client_ports() would give a bogus warning for
every nonlocal port every time it parsed any ports at all. So if it
parsed a nonlocal socksport, it would complain that it had a nonlocal
socksport...and then turn around and complain about the nonlocal
socksport again, calling it a nonlocal transport or nonlocal dnsport,
if it had any of those.
Fixes bug 7836; bugfix on 0.2.3.3-alpha.
|
| | | | |
|
|\ \ \ \ |
|
|/ / / /
| | | |
| | | |
| | | | |
Fixes bug 7814; bugfix on 0.2.4.7-alpha.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
mr-4 reports on #7799 that he was seeing it several times per second,
which suggests that things had gone very wrong.
This isn't a real fix, but it should make Tor usable till we can
figure out the real issue.
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \ |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
I think this is actually his third code review of this branch so far.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Close the circuit (it's probably junk anyways), and make sure we don't probe
it/count it as a success.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We need to use the success count or the use count depending on the consensus
parameter.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Let's hope this solves the rounding error issue..
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
For consistency and great justice.
Ok, mostly consistency.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Since we've generalized what we can count from (first or second hop), we
should generalize the variable and constant naming too.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This has several advantages, including more resilience to ambient failure.
I still need to rename all the first_hop vars tho.. Saving that for a separate
commit.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Also add some comments.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Also improve some log messages.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Also, improve and log some failure cases.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Unexpected channel closures count as remote circ failures.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Cpath is apparently good enough.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Is this redundant? Can we always rely on circ->cpath->extend_info
being present for origin circuits?
|
| | | | | |
|
| | | | | |
|