aboutsummaryrefslogtreecommitdiff
path: root/src/or/onion.c
Commit message (Collapse)AuthorAge
* Merge remote-tracking branch 'public/bug9635'Nick Mathewson2014-05-01
|\
| * Give specific warnings when client-side onionskin handshakes failNick Mathewson2014-03-27
| | | | | | | | Fix for bug9635.
* | scan-build: Have clear_pending_onions walk the lists more obviouslyNick Mathewson2014-04-18
|/ | | | | | | As it stands, it relies on the fact that onion_queue_entry_remove will magically remove each onionskin from the right list. This patch changes the logic to be more resilient to possible bugs in onion_queue_entry_remove, and less confusing to static analysis tools.
* Add explicit check for 0-length extend2 cellsNick Mathewson2014-01-03
| | | | | | This is harmless in the Tor of today, but important for correctness. Fixes bug 10536; bugfix on 0.2.4.8-alpha. Reported by "cypherpunks".
* Merge branch 'maint-0.2.4'Roger Dingledine2013-09-05
|\
| * Revert e443beff and solve it a different wayRoger Dingledine2013-09-05
| | | | | | | | | | | | | | | | | | Now we explicitly check for overflow. This approach seemed smarter than a cascade of "change int to unsigned int and hope nothing breaks right before the release". Nick, feel free to fix in a better way, maybe in master.
| * don't let recently_chosen_ntors overflowRoger Dingledine2013-09-05
| | | | | | | | | | | | with commit c6f1668d we let it grow arbitrarily large. it can still overflow, but the damage is very small now.
* | Merge branch 'maint-0.2.4'Roger Dingledine2013-09-04
|\| | | | | | | | | Conflicts: src/test/test.c
| * nickm wants us to prioritize tap in a currently-rare edge caseRoger Dingledine2013-09-04
| |
| * Be more general in calculating expected onion queue processing timeRoger Dingledine2013-09-04
| | | | | | | | | | Now we consider the TAP cells we'll process while draining the NTor queue, and vice versa.
| * let the NumNTorsPerTAP consensus param override our queue choiceRoger Dingledine2013-09-04
| |
| * do a lopsided round-robin between the onion queuesRoger Dingledine2013-09-04
| | | | | | | | | | that way tap won't starve entirely, but we'll still handle ntor requests quicker.
| * check bounds on handshake_type more thoroughlyRoger Dingledine2013-09-04
| |
| * add info-level logs to help track onion queue sizesRoger Dingledine2013-09-04
| |
| * refactor and give it unit testsRoger Dingledine2013-09-04
| |
| * Separate cpuworker queues by handshake typeRoger Dingledine2013-09-04
| | | | | | | | | | | | Now we prioritize ntor create cells over tap create cells. Starts to address ticket 9574.
* | fix typosRoger Dingledine2013-08-23
| |
* | Fix #9108 - make global_circuitlist a doubly linked listMarek Majkowski2013-06-20
|/
* Fix a warning when building with --disable-curve25519Nick Mathewson2013-02-04
| | | | | It appears that the code for 7291 gave an unused-value warning when built with --disable-curve25519.
* Rename all of the macros in tor_queue.h to start with TOR_Nick Mathewson2013-01-30
|
* Merge branch 'time_based_onionqueue_v2' of ssh://git-rw.torproject.org/nickm/torAndrea Shepard2013-01-24
|\
| * 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.
* | Update the copyright date to 201.Nick Mathewson2013-01-16
| |
* | Clean up odds and endsRoger Dingledine2013-01-15
| |
* | Fix handling of ntor handshakes received via CREATE cellsNick Mathewson2013-01-15
|/ | | | Fixes bug 7959; bugfix on 0.2.4.8-alpha.
* Complete all DOCDOC entries from the ntor branchNick Mathewson2013-01-03
|
* ntor: Don't fail fast server-side on an unrecognized KEYID(B)Nick Mathewson2013-01-03
|
* Fix an unused-variable warningNick 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
|
* 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.
* 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.
* 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.
* 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.
* Merge remote-tracking branch 'origin/maint-0.2.3'Nick Mathewson2012-11-08
|\ | | | | | | | | | | Conflicts: src/common/crypto.c src/or/rendservice.c
| * Add and use and unlikely-to-be-eliminated memwipe()Nick Mathewson2012-11-08
| | | | | | | | | | | | | | | | | | | | Apparently some compilers like to eliminate memset() operations on data that's about to go out-of-scope. I've gone with the safest possible replacement, which might be a bit slow. I don't think this is critical path in any way that will affect performance, but if it is, we can work on that in 0.2.4. Fixes bug 7352.
* | Switch onion.c over to channel_tAndrea Shepard2012-10-08
|/
* Update copyright dates to 2012; add a few missing copyright statementsNick Mathewson2012-06-04
|
* Add about 60 more DOCDOC comments to 0.2.3Nick Mathewson2012-06-04
| | | | | | | | Also, try to resolve some doxygen issues. First, define a magic "This is doxygen!" macro so that we take the correct branch in various #if/#else/#endifs in order to get the right documentation. Second, add in a few grouping @{ and @} entries in order to get some variables and fields to get grouped together.
* Rename nonconformant identifiers.Nick Mathewson2012-01-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes bug 4893. These changes are pure mechanical, and were generated with this perl script: /usr/bin/perl -w -i.bak -p s/crypto_pk_env_t/crypto_pk_t/g; s/crypto_dh_env_t/crypto_dh_t/g; s/crypto_cipher_env_t/crypto_cipher_t/g; s/crypto_digest_env_t/crypto_digest_t/g; s/aes_free_cipher/aes_cipher_free/g; s/crypto_free_cipher_env/crypto_cipher_free/g; s/crypto_free_digest_env/crypto_digest_free/g; s/crypto_free_pk_env/crypto_pk_free/g; s/_crypto_dh_env_get_dh/_crypto_dh_get_dh/g; s/_crypto_new_pk_env_rsa/_crypto_new_pk_from_rsa/g; s/_crypto_pk_env_get_evp_pkey/_crypto_pk_get_evp_pkey/g; s/_crypto_pk_env_get_rsa/_crypto_pk_get_rsa/g; s/crypto_new_cipher_env/crypto_cipher_new/g; s/crypto_new_digest_env/crypto_digest_new/g; s/crypto_new_digest256_env/crypto_digest256_new/g; s/crypto_new_pk_env/crypto_pk_new/g; s/crypto_create_crypto_env/crypto_cipher_new/g; s/connection_create_listener/connection_listener_new/g; s/smartlist_create/smartlist_new/g; s/transport_create/transport_new/g;
* Merge remote-tracking branch 'public/3122_memcmp_squashed' into ↵Nick Mathewson2011-05-11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bug3122_memcmp_022 Conflicts throughout. All resolved in favor of taking HEAD and adding tor_mem* or fast_mem* ops as appropriate. src/common/Makefile.am src/or/circuitbuild.c src/or/directory.c src/or/dirserv.c src/or/dirvote.c src/or/networkstatus.c src/or/rendclient.c src/or/rendservice.c src/or/router.c src/or/routerlist.c src/or/routerparse.c src/or/test.c
| * Hand-conversion and audit phase of memcmp transitionNick Mathewson2011-05-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Here I looked at the results of the automated conversion and cleaned them up as follows: If there was a tor_memcmp or tor_memeq that was in fact "safe"[*] I changed it to a fast_memcmp or fast_memeq. Otherwise if there was a tor_memcmp that could turn into a tor_memneq or tor_memeq, I converted it. This wants close attention. [*] I'm erring on the side of caution here, and leaving some things as tor_memcmp that could in my opinion use the data-dependent fast_memcmp variant.
| * Automated conversion of memcmp to tor_memcmp/tor_mem[n]eqNick Mathewson2011-05-11
| | | | | | | | | | | | | | | | | | | | | | | | This commit is _exactly_ the result of perl -i -pe 's/\bmemcmp\(/tor_memcmp\(/g' src/*/*.[ch] perl -i -pe 's/\!\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch] perl -i -pe 's/0\s*==\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch] perl -i -pe 's/0\s*!=\s*tor_memcmp\(/tor_memneq\(/g' src/*/*.[ch] git checkout src/common/di_ops.[ch] git checkout src/or/test.c git checkout src/common/test.h
| * Make the DH parameter we use for TLS match the one from Apache's mod_sslNick Mathewson2011-02-10
| | | | | | | | | | | | | | | | Our regular DH parameters that we use for circuit and rendezvous crypto are unchanged. This is yet another small step on the path of protocol fingerprinting resistance. (Backport from 0.2.2's 5ed73e3807d90dd0a3)
* | Handle failing cases of DH allocationNick Mathewson2011-01-25
| |
* | Make the DH parameter we use for TLS match the one from Apache's mod_sslNick Mathewson2011-01-24
| | | | | | | | | | | | Our regular DH parameters that we use for circuit and rendezvous crypto are unchanged. This is yet another small step on the path of protocol fingerprinting resistance.
* | Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2Nick Mathewson2011-01-15
|\| | | | | | | | | | | | | | | | | Conflicts: src/or/config.c src/or/networkstatus.c src/or/rendcommon.c src/or/routerparse.c src/or/test.c
generated by cgit v1.2.3 (git 2.25.4) at 2024-05-28 17:11:32 +0000