| Age | Commit message (Collapse) | Author |
|---|
|
This commit was made mechanically by this perl script:
\#!/usr/bin/perl -w -i -p
next if /^#define FREE_AND_NULL/;
s/\bFREE_AND_NULL\((\w+),/FREE_AND_NULL\(${1}_t, ${1}_free_,/;
s/\bFREE_AND_NULL_UNMATCHED\(/FREE_AND_NULL\(/;
|
|
|
|
|
|
|
|
|
|
Conflicts:
src/test/test.c
|
|
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
By now, support in the network is widespread and it's time to require
more modern crypto on all Tor instances, whether they're clients or
servers. By doing this early in 0.2.6, we can be sure that at some point
all clients will have reasonable support.
|
|
Also, refactor the way we handle failed handshakes so that this
warning doesn't propagate itself to "onion_skin_client_handshake
failed" and "circuit_finish_handshake failed" and
"connection_edge_process_relay_cell (at origin) failed."
Resolves warning from 9635.
|
|
|
|
Before I started coding ntor in C, I did another one in Python.
Turns out, they interoperate just fine.
|
|
|
|
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.
|
|
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.
|
|
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.
|
