[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-dev] Sanitizing bridge descriptors containing ed25519 fields
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Forwarding from a private thread with Nick.
- -------- Forwarded Message --------
Subject: Re: Whoops
Date: Fri, 29 May 2015 21:20:57 +0200
From: Karsten Loesing <karsten@xxxxxxxxxxxxxx>
To: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Ugh, long mail ahead. This turns out to be more difficult than
expected...
On 29/05/15 19:29, Nick Mathewson wrote:
> On Fri, May 29, 2015 at 11:04 AM, Karsten Loesing
> <karsten@xxxxxxxxxxxxxx> wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>
>> Sure!
>>
>> My main question is which of these new fields we'll have to
>> sanitize in bridge descriptors.
>>
>> The current idea of sanitizing bridge identities is that Tonga
>> would give out server descriptors if you give it a bridge
>> identity. We want to avoid that, which is why we're SHA1()'ing
>> fingerprints and removing cryptographic material.
>>
>> What about the new identity? Would we have to sanitize that in
>> any way? And if so, would we want to SHA1() it, or is there a
>> more ed25519y way to do this?
>>
>> I guess the better question might be: are there plans for Tonga
>> to give out descriptors if you tell it an ed25519 identity? If
>> not, do you see any potential trouble in leaving it unchanged in
>> sanitized bridge descriptors?
>>
>
> I would suggest that we sanitize all the crosscert stuff, and the
> ed25519 identity, and the ed25519 signing cert. Does this need to
> be done using some language I know? If so I'll be happy to hack
> it up for you if you point me to the current code that does it.
Thanks for the offer, really, but if I can, I'd rather want to write
this code myself once I know what it's supposed to do. The reason is
that setting up this code and providing you with sample data might be
more effort than writing it myself. Hope that's okay, too.
Only if you're curious, here's the current code that sanitizes bridge
descriptors:
https://gitweb.torproject.org/metrics-db.git/tree/src/org/torproject/ernie/db/bridgedescs/SanitizedBridgesWriter.java
But feel free to ignore that code, and let's talk conceptually or by
example.
> (The authority might someday give out bridges based on this
> information. Who knows? Not me. Better to be safe than sorry
> IMO.)
Okay.
> To sanitize an ed25519 identity, i'd suggest SHA256. Best avoid
> SHA1.
Sure, that would work.
By the way, here's how we're currently sanitizing bridge descriptors:
https://collector.torproject.org/formats.html#bridge-descriptors
Following those steps, I'd do the following things (quoting an actual
bridge descriptor as input here; edit: scrubbed potentially sensitive
fields, sorry for the linebreaks!):
> 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?
Whatever we do here, we should make it simple enough for bridge
operators to do, too, if they want to look up their bridge in Atlas or
Globe. hex-encode(SHA1(hex-decode(fingerprint))) seemed okay. We
should try to find something similar for ed25519 identities. (We
could also have tor log its "hashed ed25519 identity", but that only
works for people looking at logs.)
> platform Tor 0.2.7.1-alpha-dev on Linux protocols Link 1 2 Circuit
> 1 published 2015-05-29 17:53:38 fingerprint [scrubbed] uptime 2
> bandwidth 14971520 104857600 63488 extra-info-digest [scrubbed]
> [scrubbed]
IIRC (and it's been a while...), I'd replace E07A... with its SHA1.
So, I guess I'd replace YZpo... with its SHA256. Note that the
extra-info descriptor would contain a "router-digest" line with the
SHA1 of E07A... and be stored in a file using that identifier. In the
distant future, we'd probably store extra-info descriptors under their
SHA256.
> onion-key -----BEGIN RSA PUBLIC KEY----- [scrubbed] -----END RSA
> PUBLIC KEY----- signing-key -----BEGIN RSA PUBLIC KEY-----
> [scrubbed] -----END RSA PUBLIC KEY----- onion-key-crosscert
> -----BEGIN CROSSCERT----- [scrubbed] -----END CROSSCERT-----
I'd remove the last six lines starting at "onion-key-crosscert". (The
"onion-key" and "signing-key" lines/blocks would also be removed in
the current code.)
> ntor-onion-key-crosscert 0 -----BEGIN ED25519 CERT----- [scrubbed]
> -----END ED25519 CERT-----
That block would go away, too.
> hidden-service-dir contact [scrubbed] ntor-onion-key [scrubbed]
> reject *:* router-sig-ed25519 [scrubbed]
I
>
guess that can go away, too. We'll probably want to put in a
"router-dig-ed25519" with the SHA256 of that value.
> router-signature -----BEGIN SIGNATURE----- [scrubbed] -----END
> SIGNATURE-----
And here's the corresponding extra-info descriptor:
> extra-info euler [scrubbed] identity-ed25519 -----BEGIN ED25519
> CERT----- [scrubbed] -----END ED25519 CERT-----
Same as above, whatever that will be.
> published 2015-05-29 17:53:38 write-history 2015-05-29 15:36:42
> (14400 s) 2461696,2649088,1583104,1612800,1871872,2102272
> read-history 2015-05-29 15:36:42 (14400 s)
> 7444480,6047744,5960704,8019968,4823040,6364160
> dirreq-write-history 2015-05-29 13:36:18 (14400 s)
> 1180672,28672,618496,28672,14336,589824 dirreq-read-history
> 2015-05-29 13:36:18 (14400 s) 0,0,0,0,0,0 geoip-db-digest
> 0A1F9C09E08F6F2490E8880664D4E863D1680A12 geoip6-db-digest
> A6E9B5DE6F887315749B29F9C9F698215BE5240A dirreq-stats-end
> 2015-05-28 19:28:08 (86400 s) dirreq-v3-ips co=8,tw=8
> dirreq-v3-reqs tw=16,co=8 dirreq-v3-resp
> ok=16,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=0,busy=0
>
>
dirreq-v3-direct-dl
>
complete=0,timeout=0,running=0
> dirreq-v3-tunneled-dl complete=12,timeout=0,running=0 transport
> obfs3 [scrubbed]:54997 transport scramblesuit [scrubbed]:55749
> password=[scrubbed] transport fte [scrubbed]:7331 bridge-stats-end
> 2015-05-28 19:28:17 (86400 s) bridge-ips co=8,tw=8
> bridge-ip-versions v4=8,v6=0 bridge-ip-transports <OR>=8,obfs3=8
> router-sig-ed25519 [scrubbed]
Same
>
as above, whatever that will be.
> router-signature -----BEGIN SIGNATURE----- [scrubbed] -----END
> SIGNATURE-----
So, uhm, I realize there are quite some open questions above. Hope
you have some ideas, otherwise I'll think more about this tomorrow.
Thanks!
All the best,
Karsten
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJVaMrAAAoJEJD5dJfVqbCrJC8H/j279ZhNydUoYA6aWEuZVD9P
5ERo5C+93UMhBBJLtyOmKXSBFso/wUgo1i1XwU79n6wyxxu3D8GfVnSJGhiLdEtn
S6eDKkf4S/iPs+cBD8FYY/cMaj+lIehepRvzwlwV1BGSTubJXNMQTKgdh11urRTq
lcxrQQNheQlQwx2ekqnTzFNDRvBVwuEGNH6GneG/0aQi4Jv4F3vkPVvOnXJz3z0u
OrlhVPFp71BqkciIzv4yBEdxepXarX2zugxnLiKj0hmb6aCrM7NhjElfeoRkqeq4
ws6f997AJD6PJK97fTTTk+IaLAD6u0TtwXZv0v49On/ISSr61VU0CrJ39sCmY04=
=JdbV
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev