On Sat, May 30, 2015 at 5:16 PM, Karsten Loesing <kars...@torproject.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 30/05/15 16:44, Nick Mathewson wrote: >> On Fri, May 29, 2015 at 4:23 PM, Karsten Loesing >> <kars...@torproject.org> wrote: >>>> router euler [scrubbed] 8000 0 0 identity-ed25519 -----BEGIN >>>> ED25519 CERT----- [scrubbed] -----END ED25519 CERT----- >>> >>> Base64-decode that block, throw it into SHA256(), base64-encode >>> the result, format as block. But wouldn't the result be much >>> shorter? There's no new "fingerprint" equivalent, like >>> "fingerprint-ed25519", is there? >> >> Oh dear. That blob is a certificate, not a key. It changes over >> time, because the key that it certifies varies over time. >> >> The format is documented in section 2.1 of proposal 220; the >> actual identity key is in an extension labeled with type 04 (see >> section 2.2.1). >> >> Maybe we should add a fingerprint-ed25519 line? It would be >> redundant, but maybe valuable. What do you think? > > I took a quick look at proposal 220, but not to the point that makes > me entirely certain about this ed25519 stuff. If anything below > remains unclear, that might be because I'm not clear about it myself. > Please question everything I'm saying, even more than usual. > > Let's also include Damian on this thread. He usually has good ideas > about descriptors, and he knows about sanitizing bridge descriptors. > And let's add Isis who is working a lot with bridge descriptors, too. > (There may be more people we should ask, but hey, it's tor-dev@.) > > > So, I think a "fingerprint-ed25519" line would be useful. It would > make the bridge descriptor sanitizing process much easier. It would > also facilitate debugging network problems, because people can just > grep descriptors rather than using specialized tools that know how to > decode the cert. And with microdescriptors in place it should be okay > to add this line even if it's redundant information, because clients > would never download it.
Hm. Okay, that sounds solid enough. I'll try to hack it in tonight or Monday, and add it to prop220. > If the server descriptor in #16227 were a bridge descriptor, I'd do > the following steps for sanitizing it: > > - Remove identity-ed25519 line and subsequent crypto block. +1 > - Keep yet-to-be-added fingerprint-ed25519 line, but SHA256 its value. > - Keep extra-info digest line, but SHA1 and SHA256 its values. Suggestion: Don't use raw SHA256(x) but instead use SHA256("sanitize ID for bridge descriptor" | x) or SHA256("sanitize extra-info digest for bridge descriptor" | x). That way we don't need to worry about colliding with something else that decides to SHA256 these. > - Remove onion-key line and subsequent crypto block. > - Remove signing-key line and subsequent crypto block. > - Remove onion-key-crosscert line and subsequent crypto block. > - Remove ntor-onion-key-crosscert line and subsequent crypto block. > - Keep ntor-onion-key line, mostly because we didn't remove it so > far; unless it should be removed? > - Remove router-sig-ed25519 line. > - Remove router-signature line and subsequent crypto block. > - Add router-digest line with SHA1 of SHA1 of descriptor content and > SHA256 of SHA256 of descriptor content; the rationale is that we don't > have to write entirely new digests into the network status in order to > match "r" lines with descriptors. That all sounds fine. > > I also added the extra-info descriptor that corresponds to the server > descriptor to #16227: > > https://trac.torproject.org/projects/tor/ticket/16227#comment:5 > > I wonder, what's the best way for including the ed25519 identity in > the extra-info descriptor? How about extending the first line to: > > "extra-info Truie SHA1-of-RSA SHA256-of-ed25519" > > Possible downsides are that this additional value might break existing > code and that it might be problematic to get rid of the SHA1-of-RSA > part later. But the same issues would come up with the > "extra-info-digest" line in server descriptors, and maybe there are > good solutions. > > Otherwise, a separate "fingerprint-ed25519" line might work here, too. Plausible. > In order to sanitize such an extra-info descriptor, I'd do these steps: > > - Keep extra-info line, but SHA1 (and possibly SHA256) its value(s). See above. > - Or, keep yet-to-be-added fingerprint-ed25519 line, but SHA256 its > value. See above. > - Remove router-sig-ed25519 line. > - Remove router-signature line and subsequent crypto block. > - Add router-digest line with SHA1 of SHA1 of descriptor content and > SHA256 of SHA256 of descriptor content; same rationale as above, but > with the "extra-info-digest" line in server descriptors. > > What do you think? > Sounds fine. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev