- cypherpunks - lists.cpunks.org

National Bank of Ukraine on Bitcoin
by Anton Nesterov 10 Nov '14

10 Nov '14

"...hryvnia is the only legal tender in Ukraine, adopted by all natural and legal persons without any restriction on all territory of Ukraine for the transfer and settlement. <...> Issuing and turnover any other currencies [besides hryvnia] and using of money surrogates for payments is forbidden<...> Given the above, National Bank of Ukraine considers "virtual currency/cryptocurrency" Bitcoin as a money surrogate that isn't providing real value and can not be used by individuals and entities on the territory of Ukraine for payments, because it is contrary to the norms of Ukrainian legislation. <...> However, the international distribution of such payments attractive for illegal activities, including money laundering and financing of terrorist activities. We emphasize that user is responsible for all the risks in use "virtual currency/cryptocurrency" Bitcoin. National Bank of Ukraine as a regulator is not liable for risks and losses associated with use of "virtual currency/cryptocurrency" Bitcoin. In order to protect consumers rights and safety of money transfer, National Bank of Ukraine encourages citizens to use services of only those payment systems/settlement systems, which included the National Bank's Registry of payment systems, settlement systems, participants in these systems and service providers of payment infrastructure." So it's not says Ukraine bans Bitcoin (some media already published such statements), it says Bitcoin already illegal in Ukraine, as any currency besides hryvnia, and says govt isn't responsible for any risks with using Bitcoin. Official statement: http://bank.gov.ua/control/uk/publish/article?art_id=11879608&cat_id=80928 (in Ukrainian) Law of Ukraine "About National bank of Ukraine": http://zakon2.rada.gov.ua/laws/show/679-14 (in Ukrainian) -- https://nesterov.pw GPG key: 0CE8 65F1 9043 2B11 25A5 74A7 1187 6869 67AA 56E4 https://keybase.io/komachi/key.asc

2 1

Fwd: [Cryptography] From IP: Peter Swire looking for crypto policy expertise....
by grarpamp 10 Nov '14

10 Nov '14

---------- Forwarded message ---------- From: Peter Trei <petertrei(a)gmail.com> Date: Sun, Nov 9, 2014 at 6:59 PM Subject: [Cryptography] From IP: Peter Swire looking for crypto policy expertise.... To: "cryptography(a)metzdowd.com" <cryptography(a)metzdowd.com> Slightly off-topic, but may be of interest to some: From: Peter Swire <peter(a)peterswire.net> To: Dave Farber <dave(a)farber.net> Date: November 7, 2014 at 8:46:30 AM EST Subject: request for assistance for debate on encryption with former FBI General Counsel Hello Dave: On Monday, November 17 the New America Foundation will be hosting a debate on the topic of FBI Director Comey’s criticisms of Apple and Google for the encryption changes to their phones. The moderator will be Nancy Libin, formerly of both CDT and the Department of Justice. Former FBI General Counsel Andrew Weissmann will be presenting the Comey side of the argument. Andrew is an experienced litigator, former head of the Enron Task Force and other major prosecutions. I was in school years ago with Andrew, and the debate will be on the merits but not personal. With that said, only the best arguments will work. With that in mind, I was wondering if readers of your list might send (off-list) resources to prepare for the debate? Many people, in diverse outlets, have been writing about these topics. Although I am currently in the midst of hiring a full-time researcher, I don’t have that help at the moment. If useful, I could circulate a bibliography once the debate happens. For those in DC, the debate will be 4:00 to 5:30 p.m. at New America, address 1899 L St. NW #400. it will be webcast, and may be on C-Span. Thanks, Peter _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [tor-talk] insufficient hidden service performance is potential de-anonymizing DoS [was Re: [tor-dev] yes hello, internet supervillain here]
by grarpamp 09 Nov '14

09 Nov '14

On Sun, Nov 9, 2014 at 11:08 AM, Andrea Shepard <andrea(a)torproject.org> wrote: > Yes, and that is what it looks like. The strings 'code', 'old' and 'fail' in > the URLs seen in nachash's logs were also present as top-level directories on > his site, and he apparently had a 404 redirect to his index page - so a > buggy crawler might well produce something like the observed pattern. Who > would leave an obviously broken crawler producing nothing of interest like > that running for such a long time and O(1M) requests, though? An attack > designed to look like skiddie bullshit is starting to sound plausible. > coderman: > morals of this story: > - never assume a crash or DoS is innocuous on the Tor network. > - always get packet captures to diagnose trouble! (not just request logs) > - "the old tricks, still the best tricks..." In one of many threads, mine being 'dirty pool', there is forming a good variety of such morals to live by and areas of action to pursue. HS operators banding together to compare the above logs is one of them. You could conceivably throw the logs/pcaps from many relays and onions into a splunk.onion instance and try to mine some knowledge out of them that way. Tor is a jointly owned wide area infrastructure... seems time to apply the traditional net/sec tools to it and see what's up on your own network.

2 1

Fwd: insufficient hidden service performance is potential de-anonymizing DoS [was Re: [tor-dev] yes hello, internet supervillain here]
by coderman 09 Nov '14

09 Nov '14

---------- Forwarded message ---------- From: coderman <coderman(a)gmail.com> Date: Sun, 9 Nov 2014 02:04:59 -0800 Subject: insufficient hidden service performance is potential de-anonymizing DoS [was Re: [tor-dev] yes hello, internet supervillain here] thanks for the transparency, nachash! i am putting this conversation on tor-talk, since my replies are more noise and less dev, and the details seem to be around Tor use and configuration. On 11/8/14, Fears No One <nachash(a)observers.net> wrote: > ... Another regret is that pcaps weren't taken, but we both made > the mistake of assuming that because the DoS was mitigated that nothing > that was preserved would be all that important anymore. If there was > more to give, we would have been released it. the pcap dumps would have been most useful, as the access logs only identify state transitions. these types of attacks likely utilized many concurrent requests (perhaps just sending a few bytes of the request string at once, bit by bit, until a request is complete) performance analysis and tuning of internet sytems is difficult, and even more so in this context! (and performance in anonymity systems is easily reversed for de-anonymizing DoS) Andrea's distribution shows this type of behavior, as i would expect it: https://people.torproject.org/~andrea/loldoxbin-logs/analysis/length_distri… e.g. send small bits to keep connection active and not closed by server side client send timeouts, then around 900-1000 chars call it good and finalize the request. this may be application of slowloris type DoS to "encourage" HS operator to use a vulnerable path, or confirm via side channel. (you stated your web server bound to localhost, so the obvious ones you avoided at least :) > The box was an OpenVZ VPS (Essentially a glorified chroot jail, for > those who are unfamiliar)), so no, there was no physical hardware from > my standpoint. Thus, full disk crypto wasn't really an option. From the > standpoint of someone with root access to a dedi with OpenVZ vms, > finding hidden services that are hosted by customers is a matter of > looking for files named private_key anywhere under the /vz folder. of all the virtualization environments, i dislike OpenVZ the most. i dislike all virtual hosting, however, so don't assume this is a vote for Docker ;) pay the extra for dedi on bare metal! > Neither of us are rolling in fake internet money like the drug market > operators (Hint: This should indicate to anyone thinking of asking if we > ran bitcoind that we didn'), so the other alternatives were to either > use rooted boxes or flip a coin to decide who gets to host from home. ok, maybe a dedi not an option if you're that tight for cash... :/ > ... As was the tradition with doxbin boxes, the registration info > usually either went back to ... Keith Alexander... i find this amusing! my only suggestion is that you incorporate his nickname, Keith "Cowboy" Alexander > I don't have an exact time, but by around 13:00 UTC or so on the 6th, > the box was down. When the Silk Road 2.0 seizure news broke, doxbin was > already gone. I checked the most current doxbin onion and attempted to > ssh into the box every couple of hours for around the first 24 hours, > until a friend pointed out that one of the old doxbin onions was serving > up the Silk Road 2.0 seizure page. At the time, the main onion was > serving up some 404 page (Which I expected to eventually point to some > sort of honeypot, but the pigs really let me down on that one), while > other onions were unresponsive. This had changed by the next day, when > all the onions from the doxbin box were pointed to the seizure page. The > speculation has been that the cops were adding onions one at a time, and > my personal experience supports that. Police who are dedicated to > seizing and taking control of hidden services are still struggling with > managing a torrc file efficiently. Go figure. yup. hence slappy fights over the HSDir descriptor publishing is going to be effective for who knows how long... > There was some downtime on the box maybe a month ago, which I originally > thought was when it got imaged pre-seizure, once all this drama began. I > can't look at the access log report numbers and say "This is the date, > because there's a huge dip in traffic" so I'm going to have to get back > with you on that. The fact that they were adding onions to the seizure > box over 24 hours after the takendown might suggest that they for some > reason didn't image it beforehand, which would be a curious break from > their habits as laid out in past criminal complaints. this was an international effort, so perhaps just one hand not talking to the other, is the only conclusion to be drawn. > An update: All of the access log reports ever generated for doxbin can > be now be downloaded from the URLs in my initial e-mail. Other people > wanted some of them to compare to the DoS log reports, so now they can > pick their own control group. thanks for this, while not as useful as PCAPs with headers, it is still useful! > P.S. Neither of us have been arrested or have even noticed any signs of > in-person heat (Cleaning vans, new neighbors, etc), which also seems to > point to the doxbin seizure being half-cocked. how would you know what covert heat looks like? *grin* > Here until I'm in handcuffs, don't plea out! P.S. public key? best regards,

1 0

Re: [Cryptography] $750k Fine for exporting crypto
by John Young 08 Nov '14

08 Nov '14

The global internal rot of digital technology dependence appears doing quite well by inducing ever greater investment and reliance upon it. Will over-reliance upon secret cryptography be its Achilles heel? Let us hope so. Conumdrum is that wholesale monitoring is the result of ubiquitous digital technology, networks and programs thickly hidden by secret cryptography, thinly protected, if at all, by never quite effective public cryptography, ineffective by law by design, by implementation and by endless excuses to do better next time. The correlation between the rise of the Internet to advance global surveillance and public cryptography to persuade the populace there is hope the surveillance can be countered, is occasionally noted but not by cryptography fetishists who promote the notion it is possible to have a global platform of diverse levels for multiple open and secret uses but still protect at least a few of the levels with encryption. This despite the legacy of cryptography as a deceptive technology through and through and foremost, in particular by misleading about its strengths and weaknesses, its treachery and double-dealing, its cheating and betraying, its false promises and "confessed" failures. No doubt all forms of security share these characteristics, eventual failure is the fundamental outcome of a security system subject to ceaseless attack. Every fortress fails, every weapon is surpassed, every peace treaty is transgressed, every ideology collapses, every nation is overturned; in all cases by excessive conviction that failure will not happen, and when it does, it occurs by the least expected means. After a few attempts to repair the majestic defense and prolong a regime, it finally implodes most often due to internal rot of those unable to give up comfortable convictions that munitions are invulnerable, that supreme command and control is protected against tampering, that oaths and rewards of fealty to the homeland are insurpassable. Except for the planted cheats of anonymizers and encryption. >What we are seeing today is unprecedented in American >history: Wholesale monitoring of entire populations, "just in case" >the information might be "needed" later. Saying "beware, someone >evil like Nixon could use this stuff" *misses the point*: It's bad >*even if never abused*. Its mere *existence* is abuse, no matter >who controls it. If the system were under the control of a saintly >administration consisting of nothing but good actors, and there were >a magic button that would be pressed just before they handed over >the reigns to someone not so saintly that magically erased all the >stored information and destroyed the information-gathering systems >... it would *still* be wrong.

1 0

Fwd: [Announce] GnuPG 2.1.0 "modern" released
by coderman 08 Nov '14

08 Nov '14

---------- Forwarded message ---------- From: Werner Koch <wk(a)gnupg.org> Date: Thu, 06 Nov 2014 10:01:51 +0100 Subject: [Announce] GnuPG 2.1.0 "modern" released Hello! The GnuPG Project is pleased to announce the availability of a new release: Version 2.1.0. The GNU Privacy Guard (GnuPG) is a complete and free implementation of the OpenPGP standard as defined by RFC-4880 and better known as PGP. GnuPG, also known as GPG, allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. A wealth of frontend applications and libraries making use of GnuPG are available. Since version 2 GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Three different versions of GnuPG are actively maintained: - GnuPG "modern" (2.1) is the latest development with a lot of new features. This announcement is about the first release of this version. - GnuPG "stable" (2.0) is the current stable version for general use. This is what most users are currently using. - GnuPG "classic" (1.4) is the old standalone version which is most suitable for older or embedded platforms. You may not install "modern" (2.1) and "stable" (2.0) at the same time. However, it is possible to install "classic" (1.4) along with any of the other versions. What's New in GnuPG-2.1 ======================= - The file "secring.gpg" is not anymore used to store the secret keys. Merging of secret keys is now supported. - All support for PGP-2 keys has been removed for security reasons. - The standard key generation interface is now much leaner. This will help a new user to quickly generate a suitable key. - Support for Elliptic Curve Cryptography (ECC) is now available. - Commands to create and sign keys from the command line without any extra prompts are now available. - The Pinentry may now show the new passphrase entry and the passphrase confirmation entry in one dialog. - There is no more need to manually start the gpg-agent. It is now started by any part of GnuPG as needed. - Problems with importing keys with the same long key id have been addressed. - The Dirmngr is now part of GnuPG proper and also takes care of accessing keyserver. - Keyserver pools are now handled in a smarter way. - A new format for locally storing the public keys is now used. This considerable speeds up operations on large keyrings. - Revocation certificates are now created by default. - Card support has been updated, new readers and token types are supported. - The format of the key listing has been changed to better identify the properties of a key. - The gpg-agent may now be used on Windows as a Pageant replacement for Putty in the same way it is used for years on Unix as ssh-agent replacement. - Creation of X.509 certificates has been improved. It is now also possible to export them directly in PKCS#8 and PEM format for use on TLS servers. A detailed description of the changes can be found at https://gnupg.org/faq/whats-new-in-2.1.html . Getting the Software ==================== Please follow the instructions found at https://gnupg.org/download/ or read on: GnuPG 2.1.0 may be downloaded from one of the GnuPG mirror sites or direct from its primary FTP server. The list of mirrors can be found at https://gnupg.org/mirrors.html . Note that GnuPG is not available at ftp.gnu.org. On ftp.gnupg.org you find these files: ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2 (3039k) ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-2.1.0.tar.bz2.sig This is the GnuPG 2.1 source code compressed using BZIP2 and its OpenPGP signature. ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe (6225k) ftp://ftp.gnupg.org/gcrypt/binary/gnupg-w32-2.1.0_20141105.exe.sig This is an experimental installer for Windows including GPA as graphical key manager and GpgEX as an Explorer extension. Please de-install an already installed Gpg4win version before trying this installer. This binary version has not been tested very well, thus it is likely that you will run into problems. The complete source code for the software included in this installer is in the same directory; use the suffix ".tar.xz" instead of ".exe". Although several beta versions have been released over the course of the last years, no extensive public field test has been done. Thus it is likely that bugs will show up. Please check the mailing list archives and the new wiki https://wiki.gnupg.org for latest information on known problems and workaround. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.1.0.tar.bz2 you would use this command: gpg --verify gnupg-2.1.0.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See below for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.1.0.tar.bz2, you would run the command like this: sha1sum gnupg-2.1.0.tar.bz2 and check that the output matches the first line from the following list: 2fcd0ca6889ef6cb59e3275e8411f8b7778c2f33 gnupg-2.1.0.tar.bz2 9907cb6509a0e63331b27a92e25c1ef956caaf3b gnupg-w32-2.1.0_20141105.exe 28dc1365292c61fbb2bbae730d4158f425463c91 gnupg-w32-2.1.0_20141105.tar.xz Release Signing Keys ==================== To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: 2048R/4F25E3B6 2011-01-12 Key fingerprint = D869 2123 C406 5DEA 5E0F 3AB5 249B 39D2 4F25 E3B6 Werner Koch (dist sig) rsa2048/E0856959 2014-10-29 Key fingerprint = 46CC 7308 65BB 5C78 EBAB ADCF 0437 6F3E E085 6959 David Shaw (GnuPG Release Signing Key) <dshaw 'at' jabberwocky.com> rsa2048/33BD3F06 2014-10-29 Key fingerprint = 031E C253 6E58 0D8E A286 A9F2 2071 B08A 33BD 3F06 NIIBE Yutaka (GnuPG Release Key) <gniibe 'at' fsij.org> rsa2048/7EFD60D9 2014-10-19 Key fingerprint = D238 EA65 D64C 67ED 4C30 73F2 8A86 1B1C 7EFD 60D9 Werner Koch (Release Signing Key) You may retrieve these files from the keyservers using this command gpg --recv-keys 249B39D24F25E3B6 04376F3EE0856959 \ 2071B08A33BD3F06 8A861B1C7EFD60D9 The keys are also available at https://gnupg.org/signature_key.html and in the released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed using my standard PGP key. Internationalization ==================== This new branch of GnuPG has support for 4 languages: French, German, Japanese, and Ukrainian. More translations can be expected with the next point releases. Documentation ============= If you used GnuPG in the past you should read the description of changes and new features at doc/whats-new-in-2.1.txt or online at https://gnupg.org/faq/whats-new-in-2.1.html The file gnupg.info has the complete user manual of the system. Separate man pages are included as well but they have not all the details available in the manual. It is also possible to read the complete manual online in HTML format at https://gnupg.org/documentation/manuals/gnupg/ or in Portable Document Format at https://gnupg.org/documentation/manuals/gnupg.pdf . The chapters on gpg-agent, gpg and gpgsm include information on how to set up the whole thing. You may also want search the GnuPG mailing list archives or ask on the gnupg-users mailing lists for advise on how to solve problems. Many of the new features are around for several years and thus enough public knowledge is already available. Support ======= Please consult the archive of the gnupg-users mailing list before reporting a bug <https://gnupg.org/documentation/mailing-lists.html>. We suggest to send bug reports for a new release to this list in favor of filing a bug at <https://bugs.gnupg.org>. For commercial support requests we keep a list of known service companies at: https://gnupg.org/service.html The driving force behind the development of GnuPG is the company of its principal author, Werner Koch. Maintenance and improvement of GnuPG and related software takes up most of their resources. To allow him to continue this work he kindly asks to either purchase a support contract, engage g10 Code for custom enhancements, or to donate money: https://gnupg.org/donate/ Thanks ====== We have to thank all the people who helped with this release, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, and answering questions on the mailing lists. A final big Thank You goes to Hal Finney, who too early passed away this year. Hal worked on PGP and helped to make OpenPGP a great standard; it has been a pleasure having worked with him.

5 5

Darknets/science vs. GPA/LEA/Law, and playing dirty pool
by grarpamp 08 Nov '14

08 Nov '14

On Fri, Nov 7, 2014 at 9:29 AM, Öyvind Saether <oyvinds(a)everdot.org> wrote: >> http://www.bbc.com/news/technology-29950946 > > "The BBC understands that the raid represented both a technological > breakthrough - with police using new techniques to track down the > physical location of dark net servers" > > They do have the capability to locate Tor hidden services at this point. > > To those who want to pretend otherwise: The first step to fixing a > problem is to admit that it exists. There is no point in pretending > these .onion sites are secure anymore. The only interesting question > now is: How can this be fixed? > > They could simply look for high amounts of Tor traffic and pull the > plug in IPs whos traffic pattern look like it may be a hidden service > and see if anything goes down. This is a critical weakness of any anonymous system if... the way things are looking worldwide, GPA's seem to be the real deal and they seem to have no problem handing off to the LE side, and laws be damned... well, the old ways are over, it's the Wild West. Filling all the network links with chaff could be a way to protect users (maybe they were just loading the homepage over and over), but they could still bounce all the IP's to look for servers. There may be an oppurtunity for the operators of anonymous services to band together and monitor themselves or each other for bounces simply to confirm if bounce tests are infact happening against all such service participants, high data/connection rate ones, services based on age of identity key, or any other such class they are able to identify. And they'd have to characterize true bounces from network reachability anomalys. This is hard to defend against. Store-and-forward... maybe. Decentralized p2p/blockchain... more likely, at least for market-like things that could be modeled as transaction-listing-like things. Another way to test is for someone to use perfect opsec (wifi, tor, bitcoin, etc), and actually run a number of illegal sites and see what happens. Then consider some sites may be allowed to live even if actionable, or simply won't be taken down if there are no real world links to act on. Tor had one recent whitepaper that claimed to have actually located hidden services (real or test) within a minor budget and timeframe by abusing nothing other than the Tor network itself. Right? Has anyone replicated that work? People need to be analysing these court documents very carefully to see what bits of knowledge can be drawn from them. That's a project in itself and EFF/Tor wiki would be a good home to begin cataloging them all and making notes of such things in each case. It's pretty obvious something is going on besides opsec, especially with the quotes in the news. Question is, what is it? Tests need done, knowledge needs found, capabilities need catalogued, and defenses need developed. Step by step, scientific method. While you're at it, play some dirty pool in return, set up a bounty for leakers. Cash, sex, drugs, whatever. Not everyone is motivated by the same things Ellsberg/Snowden et al are. > Regardless of how it is actually done: It seems perfectly clear that > they are able to identify the servers hosting hidden services. Those > who pretend otherwise at this point are either cointelpro/military/law > enforcement or morons.

1 2

Re: [Cryptography] Third amendment crypto defenses
by grarpamp 07 Nov '14

07 Nov '14

On Fri, Nov 7, 2014 at 4:37 PM, Steve Furlong <demonfighter(a)gmail.com> wrote: > On Fri, Nov 7, 2014 at 2:46 PM, Phillip Hallam-Baker <phill(a)hallambaker.com> > wrote: >> >> I think there is a reasonable interpretation >> which would find that the military should not have anything to do with >> such activities. > > Check the cypherpunks archives from 2001 or 2002. This is not a new idea. http://www.metzdowd.com/mailman/listinfo/cryptography Forwarding context to cpunks... http://scholarship.law.wm.edu/wmborj/vol2/iss1/4 http://www.usatoday.com/story/opinion/2013/07/22/third-amendment-nsa-spying… http://misguidedchildren.com/technology/2014/01/nsa-violating-3rd-amendment…

1 0

Node Operators Web Of Trust
by grarpamp 07 Nov '14

07 Nov '14

Is it not time to establish a node operator web of trust? Look at all the nodes out there with or without 'contact' info, do you really know who runs them? Have you talked with them? What are their motivations? Are they your friends? Do you know where they work, such as you see them every day stocking grocery store, or in some building with a badge on it? Does their story jive? Are they active in the community/spaces we are? Etc. This is huge potential problem. NOWoT participation is optional, it is of course infiltratable, and what it proves may be arguable, but it seems a necessary thing to try as a test of that and to develop a good model. Many operators know each other in person. And the node density per geographic region supports getting out to meet operators even if only for the sole purpose of attesting 'I met this blob of flesh who proved ownership of node[s] x'. That's a big start, even against the sybil agents they'd surely send out to meet you. Many know exactly who the other is in the active community such that they can attest at that level. And so on down the line of different classes of trust that may be developed and asserted over each claimed operator. Assuming a NOWoT that actually says something can be established, is traffic then routable by the user over nodes via trust metrics in addition to the usual metrics and randomness? WoT's are an ancient subject... now what are the possibilities and issues when asserting them over physical nodes, not just over virtual nodes such as an email address found in your pubkey? And what about identities that exist only anonymously yet can prove control over various unique resources? If such WoT's cannot be proven to have non-value, then it seems worth doing. This doesn't just apply to Tor, but to any node based system.

1 0

Re: [tor-relays] [tor-talk] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
by grarpamp 07 Nov '14

07 Nov '14

On Thu, Nov 6, 2014 at 2:43 AM, David Serrano <tor(a)dserrano5.es> wrote: > On 2014-11-05 23:58:43 (-0500), grarpamp wrote: >> >> The real problem below is the 96% allocation of opensource to >> Linux and 4% to Other opensource. > >> Someone should really do an analysis of platform vs. exit bandwidth >> as well. Anyone? > > Here ya go. Observed bandwidth per OS in relays having the exit flag: > > 93.62% 4459816582 Linux > 4.51% 214639363 FreeBSD > 1.25% 59672066 Windows > 0.25% 11754598 Darwin > 0.17% 7896687 Bitrig > 0.15% 6964863 OpenBSD > 0.06% 3091495 SunOS This excessive Linux dominance in both node count and bandwidth really should be balanced out, like why not? I'd expect if some of the big relays switch to any other OS that would flatten out the bandwidth part pretty easily. You'd have to check say the top 10, 25, 50 or so relays to see to what extent they are part of this mess, I'm sure it's similar.

1 0