Re: [tor-dev] Proposal 220 (revised): Migrate server identity keys to Ed25519
On Sun, Aug 17, 2014 at 8:40 PM, Sebastian Hahn hahn@web.de wrote: Hi Nick, On 25 Feb 2014, at 17:18, Nick Mathewson ni...@torproject.org wrote: To mirror the way that authority identity keys work, we'll fully support keeping Ed25519 identity keys offline; they'll be used to sign long-ish term signing keys, which in turn will do all of the heavy lifting. A signing key will get used to sign the things that RSA1024 identity keys currently sign. There was a discussion of this point on tor-talk just now. s7r (one of the nice support people) was also present, maybe he will follow up here as well. Basically, the operational complexity of doing this seems to be under-appreciated here, and we're wondering if the added code complexity can possibly be worth it. Maybe we should ask some of the super big relays to weigh in. Hi, Sebastian! To clarify here, since I don't think I explained well enough in the proposal: this feature is meant to allow offline identity keys, but not require them. If the identity key is online and readable by the Tor process, Tor should generate new signing keys as needed. I think that having a multi-layer key structure like this is possibly beneficial, even for environments where managing signing key rotation is too hard. For example: * The identity key could be owned by a different user or kept in a separate VM (or maybe a hardware component? ha, ha.) and only the signing keys could be delivered to the Tor user. This is the kind of thing that an OS or package could manage. * In systems with fine-grained filesystem access controls, the Tor process could drop the ability to read the identity key at startup, right after making sure that it has enough signing keys. Or, the identity key could be isolated in a process that does nothing but generate signing keys and their certificates. * Even without access controls, we could arrange for identity keys to be purged from RAM whenever we're not actually generating a signing key, and handled by a separate process that doesn't talk to the network. This would make it impossible for a memory-exposure bug (like heartbleed) to expose identity keys. All that said, I'd also like to know what relay admins think of the practicalities here. best wishes, -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 220 (revised): Migrate server identity keys to Ed25519
Hi Nick, On 25 Feb 2014, at 17:18, Nick Mathewson ni...@torproject.org wrote: To mirror the way that authority identity keys work, we'll fully support keeping Ed25519 identity keys offline; they'll be used to sign long-ish term signing keys, which in turn will do all of the heavy lifting. A signing key will get used to sign the things that RSA1024 identity keys currently sign. There was a discussion of this point on tor-talk just now. s7r (one of the nice support people) was also present, maybe he will follow up here as well. Basically, the operational complexity of doing this seems to be under-appreciated here, and we're wondering if the added code complexity can possibly be worth it. Maybe we should ask some of the super big relays to weigh in. Cheers Sebastian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal 220 (revised): Migrate server identity keys to Ed25519
Nick Mathewson ni...@torproject.org writes: I've revised proposal 220 based on commentary from Roger. The biggest changes is tweaking all of the things called certificates to make them actually follow the same format to greatest the extent possible. To see diffs, you can use git, or browse the gitweb site at https://gitweb.torproject.org/torspec.git/history/HEAD:/proposals/220-ecc-id-keys.txt The proposal looks good. Below you can find some nitpicks. snip The EXTENSIONS field contains zero or more extensions, each of the format: ExtLength [1 or 2 bytes] ExtType [1 or 2 bytes] ExtData [Length bytes] The ExtLength and ExtType fields can represent values between 0 and 2^15-1, representing values under 128 as 0xxx and values over 128 as 1xxx . The meaning of the ExtData field in an extension is type-dependent. Ugh. Do these multi-sized fields look nasty only to me? Parsing them will not be too hard, but it definitely increases the parsing complexity. And just to save two bytes per extension _when_ extensions are used? I think I would personally upgrade both fields to 2 bytes. Except if these credentials will get passed around in great numbers. It is an error for an extension to be truncated; such a certificate is invalid. Before processing any certificate, parties MUST know which identity key it is supposed to be signed by, and then check the signature. The signature is formed by signing the first N-64 bytes of the certificate prefixed with the string Tor node signing key certificate v1. 2.2. Basic extensions 2.2.1. Signed-with-ed25519-key extension [type 04] In several places, it's desirable to bundle the key signing a certificate along with the certificate. We do so with this extension. ExtLength = 32 ExtData = An ed25519 key[32 bytes] When this extension is present, it MUST match the key used to sign the certificate. This is a nickmism. 2.3. Revoking keys. We also specify a revocation document for revoking a signing key or an identity key. Its format is: FIXED_PREFIX[8 Bytes] VERSION [1 Byte] KEYTYPE [1 Byte] IDENTITY_KEY[32 Bytes] REVOKED_KEY [32 Bytes] PUBLISHED [8 Bytes] REV_EXTENSIONS [variable length, up to length of revocation document minus 64 bytes] SIGNATURE [64 Bytes] FIXED_PREFIX is REVOKEID or REVOKESK. VERSION is [01]. KEYTYPE is [01] for revoking a signing key or [02] for revoking an identity key. REVOKED_KEY is the key being revoked; IDENTITY_KEY is the node's Ed25519 identity key. PUBLISHED is the time that the document was generated, in seconds since the epoch. REV_EXTENSIONS is left for a future version of this document. The SIGNATURE is generated with the same key as in IDENTITY_KEY, and covers the entire revocation, prefixed with Tor key revocation v1. Do we need both KEYTYPE and FIXED_PREFIX? Aren't they both used to distinguish what type of key we are revoking? Using these revocation documents is left for a later specification. snip 3.2. Formats Vote and microdescriptor documents now contain an optional id field for each routerstatus section. Its format is: id SP ed25519 SP ed25519-identity NL where ed25519-identity is base64-encoded, with trailing = characters omitted. In vote documents, it may be replaced by the format: id SP ed25519 SP none NL which indicates that the node does not have an ed25519 identity. (In a microdescriptor, a lack of id line means that the node has no ed25519 identity.) [ Should the id entries in consensuses go into microdescriptors instead? I think perhaps so. -NM] Is this still valid? This section mentions microdescriptors and not consensuses. A vote or consensus document is ill-formed if it includes the same ed25519 identity key twice. 3.3. Generating votes An authority should pick which descriptor to choose for a node as before, and include the ed25519 identity key for the descriptor if it's present. As a transition, before Rule 1 and Rule 2 in 3.1 are fully enforced, authorities need a way to deal with the possibility that there might be two nodes with the same ed25519 key but different RSA keys. In that case, it votes for the one with the most recent publication date. (The existing rules already prevent an authority from voting for two servers with the same RSA identity key.) 3.4. Generating a consensus from votes This proposal requires a new consensus vote method. When we deploy it, we'll pick the next available vote method in sequence to use for this. When the new consensus method is in use, we must choose
[tor-dev] Proposal 220 (revised): Migrate server identity keys to Ed25519
I've revised proposal 220 based on commentary from Roger. The biggest changes is tweaking all of the things called certificates to make them actually follow the same format to greatest the extent possible. To see diffs, you can use git, or browse the gitweb site at https://gitweb.torproject.org/torspec.git/history/HEAD:/proposals/220-ecc-id-keys.txt Filename: 220-ecc-id-keys.txt Title: Migrate server identity keys to Ed25519 Authors: Nick Mathewson Created: 12 August 2013 Target: 0.2.x.x Status: Draft [Note: This is a draft proposal; I've probably made some important mistakes, and there are parts that need more thinking. I'm publishing it now so that we can do the thinking together.] 0. Introduction In current Tor designs, router identity keys are limited to 1024-bit RSA keys. Clearly, that should change, because RSA doesn't represent a good performance-security tradeoff nowadays, and because 1024-bit RSA is just plain too short. We've already got an improved circuit extension handshake protocol that uses curve25519 in place of RSA1024, and we're using (where supported) P256 ECDHE in our TLS handshakes, but there are more uses of RSA1024 to replace, including: * Router identity keys * TLS link keys * Hidden service keys This proposal describes how we'll migrate away from using 1024-bit RSA in the first two, since they're tightly coupled. Hidden service crypto changes will be complex, and will merit their own proposal. In this proposal, we'll also (incidentally) be extirpating a number of SHA1 usages. 1. Overview When this proposal is implemented, every router will have an Ed25519 identity key in addition to its current RSA1024 public key. Ed25519 (specifically, Ed25519-SHA-512 as described and specified at http://ed25519.cr.yp.to/) is a desirable choice here: it's secure, fast, has small keys and small signatures, is bulletproof in several important ways, and supports fast batch verification. (It isn't quite as fast as RSA1024 when it comes to public key operations, since RSA gets to take advantage of small exponents when generating public keys.) (For reference: In Ed25519 public keys are 32 bytes long, private keys are 64 bytes long, and signatures are 64 bytes long.) To mirror the way that authority identity keys work, we'll fully support keeping Ed25519 identity keys offline; they'll be used to sign long-ish term signing keys, which in turn will do all of the heavy lifting. A signing key will get used to sign the things that RSA1024 identity keys currently sign. 1.1. 'Personalized' signatures Each of the keys introduced here is used to sign more than one kind of document. While these documents should be unambiguous, I'm going to forward-proof the signatures by specifying each signature to be generated, not on the document itself, but on the document prefixed with some distinguishing string. 2. Certificates and Router descriptors. 2.1. Certificates When generating a signing key, we also generate a certificate for it. Unlike the certificates for authorities' signing keys, these certificates need to be sent around frequently, in significant numbers. So we'll choose a compact representation. VERSION [1 Byte] CERT_TYPE [1 Byte] EXPIRATION_DATE [3 Bytes] CERT_KEY_TYPE [1 byte] CERTIFIED_KEY [32 Bytes] EXTENSIONS [variable length, up to length of certificate minus 64 bytes.] SIGNATURE [64 Bytes] The VERSION field holds the value [01]. The CERT_TYPE field holds a value depending on the type of certificate. (See appendix A.1.) The CERTIFIED_KEY field is an Ed25519 public key if CERT_KEY_TYPE is [01], or a SHA256 hash of some other key type depending on the value of CERT_KEY_TYPE. The EXPIRATION_DATE is a date, given in HOURS since the epoch, after which this certificate isn't valid. (A three-byte field here will work fine until 5797 A.D.) The EXTENSIONS field contains zero or more extensions, each of the format: ExtLength [1 or 2 bytes] ExtType [1 or 2 bytes] ExtData [Length bytes] The ExtLength and ExtType fields can represent values between 0 and 2^15-1, representing values under 128 as 0xxx and values over 128 as 1xxx . The meaning of the ExtData field in an extension is type-dependent. It is an error for an extension to be truncated; such a certificate is invalid. Before processing any certificate, parties MUST know which identity key it is supposed to be signed by, and then check the signature. The signature is formed by signing the first N-64 bytes of the certificate prefixed with the string Tor node signing key certificate v1. 2.2. Basic extensions 2.2.1. Signed-with-ed25519-key extension [type 04]
