Re: [tor-dev] Tor's default behavior for ed25519 identities
On Thu, Aug 6, 2015 at 6:26 PM, s7r s...@sky-ip.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I am also sending the steps I imagine Tor should take when started as a relay. Apologies if I am missing something obvious. They are expressed as simple as possible, Tor's interpretation is way more complex than this, but I think/hope this might help with ordering and architecture of the code. The ed25519_keygen branch behaves _very_ _good_ (report in my previous email), so I am sending this only for a fast verification. It is easier to spot if the code jumps over a step if we have logic in ordering: [0] If there are no ed25519* files at all in $datadirectory/keys, generate a fresh new identity, signing key and cert, everything needed (valid for 30 days unless otherwise specified in torrc) and use those. Almost. Here's what I think is going on: 1) Load the secret signing key signing certificate. If they are absent, or expired, or if --keygen was called, we'll need to generate a new one. If it's going to expire soon, we _want_ to generate a new one. 2) If we need or want to generate a new signing key, load the master ID secret key. Otherwise, don't try. If we try to load it and it's absent or encrypted, log a message. If we need to generate a new signing key then exit on error; otherwise just warn. 2b) If we fail to load the master ID secret key, and there were no other keys in the keys directory, then generate a master ID secret key and save it. 3) Load the master ID public key. If we loaded a secret key, and it doesn't match, log and quit. If it doesn't match the master ID public key in a certificate we loaded, log and quit. If we have the public key from one of those other sources and the master ID public key file is missing, recreate it. 4) At this point, if we need to generate a new signing key and cert, and we don't have a secret master ID key, exit. 5) If we have a have a secret master ID key, and we need or want to generate a new signing key and cert, do so, and save them. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] First release of OnioNS for beta testing
Thanks Dr. Fu, I look forward to your comments. From the server log, apparently so far no one has tested the client, though someone has set up a server. I just want to highlight that I have servers up and running so the client and the HS functionality should work out of the box. For the client, install the software then follow the instructions in the README to integrate it into the Tor Browser. My current approach is to rename the Tor binary from tor to torbin and then insert a symlink to the onions-tbb executable under the name tor. Then the onions-tbb software lauches torbin, onions-client, and the Stem script in that order, thus allowing all the necessary software to start with the Tor Browser. I have also added some functionality to wait until Tor is fully bootstrapped before launching onions-client and the Stem script, thus this approach is fully compatible with Tor bridges. Jesse V. Subject: Re: [tor-dev] First release of OnioNS for beta testing From: Xinwen Fu Date: 08/08/2015 04:25 AM To: tor-dev@lists.torproject.org tor-dev@lists.torproject.org Fantastic work. Will test it. Xinwen Fu signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor's definition of 'median'
On Mon, Aug 10, 2015 at 1:11 PM, nusenu nus...@openmailbox.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2028 If 3 or more authorities provide a Measured= keyword for a router, the authorities produce a consensus containing a w Bandwidth= keyword equal to the median of the Measured= votes. a random sample from recent votes: grep 37.59.38.117 -A 3 *|grep Measured w Bandwidth=6869 Measured=7570 w Bandwidth=6869 Measured=15500 w Bandwidth=6869 Measured=18100 w Bandwidth=6869 Measured=30500 Tor says the median value is 15500 2015-08-10-16-00-00-consensus: w Bandwidth=15500 but the median of these 4 values is actually: (18100+15500)/2 = 16800 no? Has tor a different definition of 'median' and simply takes always the second ordered measurement vote out of 4 votes or is there a bug in the spec or implementation? There's one misplaced throwaway sentence in dir-spec.txt: All ties in computing medians are broken in favor of the smaller or earlier item. We should bring this, and probably other things, into a definitions section earlier in dir-spec.txt. Patches welcome. ;) -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor's definition of 'median'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2028 If 3 or more authorities provide a Measured= keyword for a router, the authorities produce a consensus containing a w Bandwidth= keyword equal to the median of the Measured= votes. a random sample from recent votes: grep 37.59.38.117 -A 3 *|grep Measured w Bandwidth=6869 Measured=7570 w Bandwidth=6869 Measured=15500 w Bandwidth=6869 Measured=18100 w Bandwidth=6869 Measured=30500 Tor says the median value is 15500 2015-08-10-16-00-00-consensus: w Bandwidth=15500 but the median of these 4 values is actually: (18100+15500)/2 = 16800 no? Has tor a different definition of 'median' and simply takes always the second ordered measurement vote out of 4 votes or is there a bug in the spec or implementation? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVyNtYAAoJEFv7XvVCELh0YU8P/0hWhCLfafvFDPdAfUwUJFPA A1ZA946JGKg1Vjy+ch3tffjDHRosXt7K5U33N9rKMUlW9ul2BQ+uNgzK4eTbghHz yCMn6D+uLk1xruYTsIUZ+Pk/ZywaUKj/FngohVvQnaJIgJCHCEnCIqqBNEK0PjUh EBzI5GdyWpEA2fh55PSRuSNCVzbiVhGwYSKgrVwFrFcKr9iPLmdZsa9SD1mb1PD1 IZOkU6TnSnFGbPaN+pHYdNr5/QJA1/08yYBpG7qAJaTCAMvMif7bKMJ7ElYo7opc oXcECIcBBPnATgKvbO47dbSnX3s+vPMsrRhhdTa1BMr1MIzVG3RWGhNSJwXXQTJh jyaPGj10JRWNxDsY0ro001MX0HymmXeLLCkY4nWsUqPXDiZcQe4oRzLQas5bOI94 ct4tCavj9pRNp2XYCWe631gqcsQ3xV7y37dWUCvpdXqt2NC1B7j2w/Y/UiuNArSj QBtS4Ap5wqnU5JySjndi+lIPOlaPk9uitmzpKLxNF9fnpI6ZECP3T50vHVeZiiQ9 7o1ZyBsPLk3bi2hRy8ZJ0wyO+5WF8bdrlsKXSR40UjrwQZ5kCQf6xmWiSg9PqZFU rIL14yCOsQkR3P4/IgMlL8dtgFk3Asmkkx039144fRKveEhffFjo54CUMhg/jLra EF5cUqz4QdgcpRvKa/5h =lA/6 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [important] sponsors deliverables discussion point for Wed's meeting
Hello Core Tor folks! Note: if you are not a contractor or full time you can ignore this email, it is about paid deliverables. Me and Nick have been working on documenting the current status of our deliverables for the year to Sponsor S [project year ends on October] and Sponsor U [project year ends on November]. The result gave us a clear picture of where we need your help with. Please take a look at: https://docs.google.com/spreadsheets/d/1dTva10mu-FcX8KrxRjgkFvHSyNy7aBpD9xehNuUeZ-4/edit?usp=sharing For Wednesday we want to figure out how can people jump in and help on these tasks. Right now we have a lot assigned to Nick and is a big red flag that we won't make it. Not to mention that Nick also has to carry on other work and to do both is just impossible. Please take a look, ask questions and lets figure out how we can conclude all this tasks. Priorities are: * Rows 5 6 * And any help on the other tasks that are all about writing docs (rows 12, 13, 15, 16, 17) * Or maybe help out with the final push for Sponsor S tasks We will be adding the related tickets (column H) later today so you can take a look before the meeting on Wednesday. thanks! isabela -- PM at TorProject.org gpg fingerprint = 8F2A F9B6 D4A1 4D03 FDF1 B298 3224 4994 1506 4C7B @isa signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Aug 10, 2015, at 2:00 PM, Philipp Winter p...@nymity.ch wrote: Vanity addresses encourage people to only verify the human-readable part of an address before clicking on it. That creates a false sense of security, which is already exploited by spoofed onion service addresses whose prefix and suffix mimics the original onion address. That does strike me as a risk. That said, if an address is completely incapable, even hostile to validation by human eyeballs, then what happens is “trust” migrates to using a bunch of tools which are forgeable, spoofable, hackable, trojanable. The resultant risk might be worse for its greater resistance to detection. -a ps: for an investigation of what happens when you build a “communities” app around “non-human-readable” barcodes and without a discovery mechanism, see this article; such innovation gives me great hope for humanity finding solutions to apparently high-friction technologies, but it also clearly hampers broader inclusiveness, the latter arguably being one of Tor’s most important goals: http://mashable.com/2014/10/24/hacks-facebook-rooms/ http://mashable.com/2014/10/24/hacks-facebook-rooms/ — Alec Muffett Security Infrastructure Facebook Engineering London signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Mon, Aug 10, 2015 at 08:47:05AM +0100, bernard wrote: On 9 Aug 2015, at 23:43, Philipp Winter p...@nymity.ch wrote: Vanity onion addresses, for example, might have done more harm than good Why do you say that? What harm would human readable .onion addresses do? And to who? Vanity addresses encourage people to only verify the human-readable part of an address before clicking on it. That creates a false sense of security, which is already exploited by spoofed onion service addresses whose prefix and suffix mimics the original onion address. Cheers, Philipp ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
