aboutsummaryrefslogtreecommitdiff
path: root/src/common/crypto_curve25519.h
AgeCommit message (Collapse)Author
2018-02-20crypto: Remove unnecessary curve25519 header from crypto_digest.h.Isis Lovecruft
* ADD includes for "torint.h" and "container.h" to crypto_digest.h. * ADD includes for "crypto_digest.h" to a couple places in which crypto_digest_t was then missing. * FIXES part of #24658: https://bugs.torproject.org/24658#comment:30
2018-01-19Add crypto_openssl_mgt.[ch] for compiling dependencies.Fernando Fernandez Mancera
Included crypto_openssl_mgt.[ch] into the appropiate files in order to resolve compiling and dependencies issues. Follows #24658. Signed-off-by: Fernando Fernandez Mancera <ffernandezmancera@gmail.com>
2017-09-15Run our #else/#endif annotator on our source code.Nick Mathewson
2017-03-15Run the copyright update script.Nick Mathewson
2016-10-17Write a bunch of module documentation.Nick Mathewson
This commit adds or improves the module-level documenation for: buffers.c circuitstats.c command.c connection_edge.c control.c cpuworker.c crypto_curve25519.c crypto_curve25519.h crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c protover.c protover.h reasons.c rephist.c replaycache.c routerlist.c routerparse.c routerset.c statefile.c status.c tor_main.c workqueue.c In particular, I've tried to explain (for each documented module) what each module does, what's in it, what the big idea is, why it belongs in Tor, and who calls it. In a few cases, I've added TODO notes about refactoring opportunities. I've also renamed an argument, and fixed a few DOCDOC comments.
2016-02-27Update the copyright year.Nick Mathewson
2015-07-31Move formatting functions around.Nick Mathewson
The base64 and base32 functions used to be in crypto.c; crypto_format.h had no header; some general-purpose functions were in crypto_curve25519.c. This patch makes a {crypto,util}_format.[ch], and puts more functions there. Small modules are beautiful!
2015-07-06Integrate the accelerated Curve25519 scalar basemult.Yawning Angel
Integration work scavanged from nickm's `ticket8897_9663_v2` branch, with minor modifications. Tor will still sanity check the output but now also attempts to catch extreme breakage by spot checking the optimized implementation vs known values from the NaCl documentation. Implements feature 9663.
2015-01-02Bump copyright dates to 2015, in case someday this matters.Nick Mathewson
2014-10-28Add another year to our copyright dates.Nick Mathewson
Because in 95 years, we or our successors will surely care about enforcing the BSD license terms on this code. Right?
2014-10-27Remove configure option to disable curve25519Sebastian Hahn
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.
2014-09-25Support for writing ed25519 public/private components to disk.Nick Mathewson
This refactors the "== type:tag ==" code from crypto_curve25519.c
2014-09-25Add Ed25519 support, wrappers, and tests.Nick Mathewson
Taken from earlier ed25519 branch based on floodyberry's ed25519-donna. Tweaked so that it applies to ref10 instead.
2014-02-07Explain CURVE25519_ENABLED: closes 9774Nick Mathewson
2013-07-10Completely refactor how FILENAME_PRIVATE worksNick Mathewson
We previously used FILENAME_PRIVATE identifiers mostly for identifiers exposed only to the unit tests... but also for identifiers exposed to the benchmarker, and sometimes for identifiers exposed to a similar module, and occasionally for no really good reason at all. Now, we use FILENAME_PRIVATE identifiers for identifiers shared by Tor and the unit tests. They should be defined static when we aren't building the unit test, and globally visible otherwise. (The STATIC macro will keep us honest here.) For identifiers used only by the unit tests and never by Tor at all, on the other hand, we wrap them in #ifdef TOR_UNIT_TESTS. This is not the motivating use case for the split test/non-test build system; it's just a test example to see how it works, and to take a chance to clean up the code a little.
2013-02-04Fix compilation with --disable-curve25519 optionNick Mathewson
The fix is to move the two functions to format/parse base64 curve25519 public keys into a new "crypto_format.c" file. I could have put them in crypto.c, but that's a big file worth splitting anyway. Fixes bug 8153; bugfix on 0.2.4.8-alpha where I did the fix for 7869.
2013-01-16Update the copyright date to 201.Nick Mathewson
2013-01-05Make the = at the end of ntor-onion-key optional.Nick Mathewson
Makes bug 7869 more easily fixable if we ever choose to do so.
2013-01-03Check all crypto_rand return values for ntor.Nick Mathewson
2013-01-02Move curve25519 keypair type to src/common; give it functionsNick Mathewson
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.
2013-01-02Add a wrapper around, and test and build support for, curve25519.Nick Mathewson
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.
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion