Age | Commit message (Collapse) | Author |
|
When size_t is the most memory you can have, make sure that things
referring to real parts of memory are size_t, not uint64_t or off_t.
But not on any released Tor.
|
|
Conflicts:
src/common/include.am
src/ext/README
|
|
Add some documentation
Rename "derive" -> "blind"
Check for failure on randombytes().
|
|
|
|
|
|
I know it's pointless to optimize them, but I just can't let them
spend all that time in expmod() when native python pow() does the same
thing.
|
|
Also, use it to generate test vectors, and add those test vectors
to test_crypto.c
This is based on ed25519.py from the ed25519 webpage; the kludgy hacks
are my own.
|
|
|
|
|
|
Our integer-definition headers apparently suck in a definition for
select(2), which interferes with the select() in ge_scalarmult_base.c
|
|
This implementation allows somebody to add a blinding factor to a
secret key, and a corresponding blinding factor to the public key.
Robert Ransom came up with this idea, I believe. Nick Hopper proved a
scheme like this secure. The bugs are my own.
|
|
For proposal 228, we need to cross-certify our identity with our
curve25519 key, so that we can prove at descriptor-generation time
that we own that key. But how can we sign something with a key that
is only for doing Diffie-Hellman? By converting it to the
corresponding ed25519 point.
See the ALL-CAPS warning in the documentation. According to djb
(IIUC), it is safe to use these keys in the ways that ntor and prop228
are using them, but it might not be safe if we start providing crazy
oracle access.
(Unit tests included. What kind of a monster do you take me for?)
|
|
This refactors the "== type:tag ==" code from crypto_curve25519.c
|
|
|
|
|
|
This will be needed/helpful for the key blinding of prop224, I
believe.
|
|
This is another case where DJB likes sticking the whole signature
prepended to the message, and I don't think that's the hottest idea.
The unit tests still pass.
|
|
Unit tests still pass.
|
|
|
|
Taken from earlier ed25519 branch based on floodyberry's
ed25519-donna. Tweaked so that it applies to ref10 instead.
|
|
(Also, regenerate trunnel stuff with trunnel 1.2. This just adds a
few comments to our output.)
|
|
Also, re-run the latest trunnel.
Closes ticket 13242
|
|
|
|
Conflicts:
src/test/test_crypto.c
|
|
|
|
This reduces the likelihood that I have made any exploitable errors
in the encoding/decoding.
This commit also imports the trunnel runtime source into Tor.
|
|
Suggested by yawning
|
|
Suggested by yawning.
|
|
Use HKDF for RFC2440 s2k only.
|
|
|
|
|
|
Doing this lets me pass in a salt of an unusual length.
|
|
See crypto_pwbox.c for a description of the file format.
There are tests for successful operation, but it still needs
error-case tests.
|
|
Uses libscrypt when found; otherwise, we don't have scrypt and we
only support openpgp rfc2440 s2k hashing, or pbkdf2.
Includes documentation and unit tests; coverage around 95%. Remaining
uncovered code is sanity-checks that shouldn't be reachable fwict.
|
|
|
|
|
|
Conflicts:
src/test/test_policy.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow clients to use optimistic data when connecting to a hidden service,
which should cut out the initial round-trip for client-side programs
including Tor Browser.
(Now that Tor 0.2.2.x is obsolete, all hidden services should support
server-side optimistic data.)
See proposal 181 for details. Implements ticket 13211.
|
|
I think we should know the routerstatus for our exit relay, since
we built a circuit to it. So I think this is just a code simplication.
|
|
Clients are now willing to send optimistic circuit data (before they
receive a 'connected' cell) to relays of any version. We used to
only do it for relays running 0.2.3.1-alpha or later, but now all
relays are new enough.
Resolves ticket 13153.
|
|
|
|
Return an error when the second or later arguments of the
"setevents" controller command are invalid events. Previously we
would return success while silently skipping invalid events.
Fixes bug 13205; bugfix on 0.2.3.2-alpha. Reported by "fpxnns".
|