summaryrefslogtreecommitdiff
path: root/src/or/routerkeys.h
AgeCommit message (Collapse)Author
2016-02-27Update the copyright year.Nick Mathewson
2015-09-22Merge branch 'feature16769_squashed'Nick Mathewson
2015-09-22Add a --master-key optionNick Mathewson
This lets the user override the default location for the master key when used with --keygen Part of 16769.
2015-09-04Never ever try to load the secret key if offline_master is setNick Mathewson
(Not even if we can't find the public key.)
2015-08-19More log messages for keygen problemsNick Mathewson
2015-07-14If loading an ed25519 master key fails with errno != ENOENT, give up.Nick Mathewson
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.
2015-06-17Support encrypted offline master keys with a new --keygen flagNick Mathewson
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.
2015-05-28Generate weird certificates correctlyNick Mathewson
(Our link protocol assumes that the link cert certifies the TLS key, and there is an RSA->Ed25519 crosscert)
2015-05-28# This is a combination of 2 commits.Nick Mathewson
# 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.
2015-05-28Only load master ed25519 secret keys when we absolutely must.Nick Mathewson
2015-05-28Implement proposal 228: cross-certification with onion keysNick Mathewson
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.
2015-05-28prop220: Implement certificates and key storage/creationNick Mathewson
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)
7apu2bq3rhoylwmucxizk54afw5jyda7pho4j5zdcqpwkufke7zdzwad.onion