| Age | Commit message (Collapse) | Author |
|---|
|
They are no longer "all" digests, but only the "common" digests.
Part of 17795.
This is an automated patch I made with a couple of perl one-liners:
perl -i -pe 's/crypto_digest_all/crypto_common_digests/g;' src/*/*.[ch]
perl -i -pe 's/\bdigests_t\b/common_digests_t/g;' src/*/*.[ch]
|
|
Closes 17403.
|
|
|
|
This lets the user override the default location for the master key
when used with --keygen
Part of 16769.
|
|
|
|
|
|
|
|
|
|
(Not even if we can't find the public key.)
|
|
When this is set, and Tor is running as a relay, it will not
generate or load its secret identity key. You can manage the secret
identity key with --keygen. Implements ticket 16944.
|
|
CID 1301373
|
|
Fixes CID 1306915, which noticed that the check was dead.
|
|
Closes ticket 16790.
|
|
|
|
|
|
|
|
|
|
|
|
Needs changes file, documentation, test integration, more tests.
|
|
|
|
|
|
We haven't implemented NO_REPAIR for NEEDCERT, and we don't need it:
but it's safest to stop any attempt to use it that way.
|
|
Teor found these. This is for part of #16582.
|
|
Make sure that signing certs are signed by the right identity key,
to prevent a recurrence of #16530. Also make sure that the master
identity key we find on disk matches the one we have in RAM, if we
have one.
This is for #16581.
|
|
When there is a signing key and the certificate lists a key, make
sure that the certificate lists the same signing key.
When there are public key and secret key stored in separate files,
make sure they match.
Use the right file name when we load an encrypted secret key and
then find a problem with it.
This is part of 16581.
|
|
This implements feature 16582: if we get EMFILE or something when
loading our master key, we should not at that point attempt to
overwrite it.
|
|
|
|
Patch from cypherpunks. Fixes bug 16449. Bug not in any released tor.
|
|
|
|
|
|
|
|
When --keygen is provided, we prompt for a passphrase when we make a
new master key; if it is nonempty, we store the secret key in a new
crypto_pwbox.
Also, if --keygen is provided and there *is* an encrypted master key,
we load it and prompt for a passphrase unconditionally.
We make a new signing key unconditionally when --keygen is provided.
We never overwrite a master key.
|
|
signing_key can be NULL in ed_key_init_from_file in routerkeys.c.
Discovered by clang 3.7 address sanitizer.
Fix on c03694938ed0, not in any released version of Tor.
|
|
|
|
|
|
|
|
|
|
CID 1301369
|
|
Found by coverity -- CID 1301366.
|
|
We need this to prevent some annoying chutney crash-at-starts
|
|
(Our link protocol assumes that the link cert certifies the TLS key,
and there is an RSA->Ed25519 crosscert)
|
|
# The first commit's message is:
Regenerate ed25519 keys when they will expire soon.
Also, have testing-level options to set the lifetimes and
expiration-tolerances of all key types, plus a non-testing-level
option to set the lifetime of any auto-generated signing key.
# The 2nd commit message will be skipped:
# fixup! Regenerate ed25519 keys when they will expire soon.
|
|
|
|
Routers now use TAP and ntor onion keys to sign their identity keys,
and put these signatures in their descriptors. That allows other
parties to be confident that the onion keys are indeed controlled by
the router that generated the descriptor.
|
|
Now that we have ed25519 keys, we can sign descriptors with them
and check those signatures as documented in proposal 220.
|
|
For prop220, we have a new ed25519 certificate type. This patch
implements the code to create, parse, and validate those, along with
code for routers to maintain their own sets of certificates and
keys. (Some parts of master identity key encryption are done, but
the implementation of that isn't finished)
|
