aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* Use a TAILQ, not a singly-linked queue, for the onion queue.Nick Mathewson2013-01-03
| | | | | | | | This makes removing items from the middle of the queue into an O(1) operation, which could prove important as we let onionqueues grow longer. Doing this actually makes the code slightly smaller, too.
* Eliminate MaxOnionsPending; replace it with MaxOnionQueueDelayNick Mathewson2013-01-03
| | | | | | | | | | | | | | | | | | The right way to set "MaxOnionsPending" was to adjust it until the processing delay was appropriate. So instead, let's measure how long it takes to process onionskins (sampling them once we have a big number), and then limit the queue based on its expected time to finish. This change is extra-necessary for ntor, since there is no longer a reasonable way to set MaxOnionsPending without knowing what mix of onionskins you'll get. This patch also reserves 1/3 of the onionskin spots for ntor handshakes, on the theory that TAP handshakes shouldn't be allowed to starve their speedier cousins. We can change this later if need be. Resolves 7291.
* Whoops; make that unit test actually pass :/Nick Mathewson2013-01-03
|
* Add a unit test for the curve25519 keypair persistence functionsNick Mathewson2013-01-03
|
* Merge branch 'ntor-resquashed'Nick Mathewson2013-01-03
|\ | | | | | | | | | | | | Conflicts: src/or/cpuworker.c src/or/or.h src/test/bench.c
| * Check all crypto_rand return values for ntor.Nick Mathewson2013-01-03
| |
| * Complete all DOCDOC entries from the ntor branchNick Mathewson2013-01-03
| |
| * Use safe_mem_is_zero for checking curve25519 output for 0-nessNick Mathewson2013-01-03
| | | | | | | | This should make the intent more explicit. Probably needless, though.
| * Implement a constant-time safe_mem_is_zero.Nick Mathewson2013-01-03
| |
| * changes file for the ntor branchNick Mathewson2013-01-03
| |
| * Document UseNTorHandshakeNick Mathewson2013-01-03
| |
| * Add new ntor bits to gitignoreNick Mathewson2013-01-03
| |
| * Add reference implementation for ntor, plus compatibility testNick Mathewson2013-01-03
| | | | | | | | | | Before I started coding ntor in C, I did another one in Python. Turns out, they interoperate just fine.
| * ntor: Don't fail fast server-side on an unrecognized KEYID(B)Nick Mathewson2013-01-03
| |
| * Update our copy of curve25519-donna-c64.Nick Mathewson2013-01-03
| | | | | | | | | | This now matches upstream at version 59a896970a1ad0a6cd7d0. (Adam took my patches.)
| * Use always_inline only with inline; otherwise GCC gripesNick Mathewson2013-01-03
| |
| * Make libcurve25519_donna get built as a .aNick Mathewson2013-01-03
| | | | | | | | | | This lets us give it compiler flags differing from the rest of libor-crypto.a
| * Fix an unused-variable warningNick Mathewson2013-01-03
| |
| * Enable the ntor handshake on the client side.Nick Mathewson2013-01-03
| | | | | | | | "works for me"
| * Enable handling of create2/extend2/created2/extended2Nick Mathewson2013-01-03
| |
| * Don't check create cells too much when we're relaying themNick Mathewson2013-01-03
| | | | | | | | | | We want to sanity-check our own create cells carefully, and other people's loosely.
| * Implement scheme to allow ntor requests/responses via older serversNick Mathewson2013-01-03
| |
| * Use created_cell_format where appropriateNick Mathewson2013-01-03
| |
| * Use new wrappers for making,sending,processing create/extend cellsNick Mathewson2013-01-03
| |
| * Teach cpuworker and others about create_cell_t and friendsNick Mathewson2013-01-03
| | | | | | | | | | | | | | | | | | | | | | 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
| * Code to parse and format CREATE{,2,_FAST} cells and their alliesNick Mathewson2013-01-03
| | | | | | | | | | | | | | | | 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.
| * Rename handshake_digest to rend_circ_nonceNick Mathewson2013-01-03
| | | | | | | | | | | | | | | | 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..
| * Massive refactoring of the various handshake typesNick Mathewson2013-01-03
| | | | | | | | | | 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.
| * Refactor the CREATE_FAST handshake code to match the others.Nick Mathewson2013-01-03
| |
| * Split onion.[ch] into onion{,_fast,_tap}.[ch]Nick Mathewson2013-01-02
| | | | | | | | | | | | | | | | | | | | 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.
| * Wrangle curve25519 onion keys: generate, store, load, publish, republishNick Mathewson2013-01-02
| | | | | | | | | | | | | | | | 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
| * Move curve25519 keypair type to src/common; give it functionsNick Mathewson2013-01-02
| | | | | | | | | | | | 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.
| * Refactor strong os-RNG into its own functionNick Mathewson2013-01-02
| | | | | | | | | | | | | | | | | | | | | | 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.
| * curve25519-donna-c64: make endian-neutralness fns staticNick Mathewson2013-01-02
| |
| * Implementat the ntor handshakeNick Mathewson2013-01-02
| | | | | | | | | | | | 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.
| * Add a wrapper around, and test and build support for, curve25519.Nick Mathewson2013-01-02
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * curve25519-donna-c64: work on bigendian and alignment-happy systemsNick Mathewson2013-01-02
| | | | | | | | | | | | | | | | 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.
| * Make curve25519-donna work with our compiler warnings.Nick Mathewson2013-01-02
| |
| * Add fallback implementations for curve25519: curve25519_donnaNick Mathewson2013-01-02
| | | | | | | | | | This is copied from Adam Langley's curve25519-donna package, as of commit 09427c9cab32075c06c3487aa01628030e1c5ae7.
| * Add a data-invariant linear-search map structureNick Mathewson2013-01-02
| | | | | | | | I'm going to use this for looking op keys server-side for ntor.
| * Add a unit test for the old KDF while we're at itNick Mathewson2012-12-06
| |
| * Implement HKDF from RFC5869Nick Mathewson2012-12-06
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * Add benchmark to test onionskin performance.Nick Mathewson2012-12-06
| |
| * Add a crypto_dh_dup, for benchmark supportNick Mathewson2012-12-06
| |
* | Avoid spurious local-port warningsNick Mathewson2013-01-02
| | | | | | | | | | | | | | | | | | | | | | 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.
* | Fix a couple of harmless clang3.2 warningsSebastian Hahn2012-12-31
| |
* | Merge branch 'bug7814_squash'Nick Mathewson2012-12-29
|\ \
| * | Fix a crash bug when running an node without IPv6-exit support.Nick Mathewson2012-12-29
|/ / | | | | | | Fixes bug 7814; bugfix on 0.2.4.7-alpha.
* | Rate-limit "No circuits are opened" message to once-per-hourNick Mathewson2012-12-26
| | | | | | | | | | | | | | | | 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.
* | Fix a possibly-unused-var warning. Thank you, GCC.Nick Mathewson2012-12-25
| |
generated by cgit v1.2.3 (git 2.25.4) at 2024-07-02 21:52:19 +0000