| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
|
|
Apparently, ref10 likes implicit conversions from int64 to int32 more
than our warnings do.
|
|
|
|
We might use libsodium or ed25519-donna later on, but for now, let's
see whether this is fast enough. We should use it in all cases when
performance doesn't matter.
|
|
|
|
It had been used in consensus method 1. But now that 13 is the
minimum (see #10163), we don't need it around.
Found by sysrqb.
|
|
This is related to the rest of 523587a5cf62119baa01822e2e783925726a790b
|
|
|
|
|
|
|
|
Using the *_array() functions here confused coverity, and was actually
a bit longer than we needed. Now we just use macros for the repeated
bits, so that we can mention a file and a suffix-appended version in
one line.
|
|
Conflicts:
src/or/circuitlist.c
|
|
Specifically, count the age of the data queued in a linked directory
connection's buffers when counting a stream's age.
|
|
Another part of 11792.
|
|
Part of 11792.
(Uses the zlib-endorsed formula for memory needs for inflate/deflate
from "zconf.h".)
|
|
We had some code to fix up the 'status' return value to -1 on error
if it wasn't set, but it was unreachable because our code was
correct. Tweak this by initializing status to -1, and then only
setting it to 0 on success. Also add a goto which was missing: its
absence was harmless.
[CID 718614, 718616]
|
|
|
|
[CID 1205014]
|
|
This allows coverity to infer that we aren't leaking them.
[Fixes a lot of CIDs]
|
|
Found by coverity, which noticed that if you said
tor-gencert -i identity1 -i identity2
we would leak "identity1".
[CID 1198201, 1198202, 1198203]
|
|
Also explain why we aren't checking its return value.
[CID 1198197]
|
|
Also, make it clearer that chunks cannot be NULL
[CID 1031750, 1031751]
|
|
The unsigned underflow here is defined and intentional.
CID 202482
|
|
This was freaking out coverity.
[CID 743379]
|
|
The unsigned underflow here is defined and intentional.
CID 202482
|
|
[CID 718609]
|
|
(We allowed it previously, but produced an LD_BUG message when it
happened, which is not consistent
Also, remove inconsistent NULL checks before calling
rend_service_intro_free.
(Removing the check is for CID 718613)
|
|
Coverity doesn't like doing NULL checks on things that can't be
NULL; I like checking things where the logic for their not being
NULL is nontrivial. Let's compromise, and make it obvious that this
field can't be NULL.
[Coverity CID 202004]
|
|
(It's LD_BUG to reach this point because the hashed password values
were tested earlier from options_validate)
[Coverity CID 1232091]
|
|
Coverity thinks that when we do "double x = int1/int2;", we probably
meant "double x = ((double)int1) / int2;". In these cases, we
didn't.
[Coverity CID 1232089 and 1232090]
|
|
[Coverity CID 1232087 and 1232088]
|
