- cypherpunks-legacy - lists.cpunks.org

[p2p-hackers] Call for Participation: The 12th Information Security Conference (ISC 2009)
by Eros Pedrini 05 Jul '18

05 Jul '18

[Apologies if you receive multiple copies of this message] CALL FOR PARTICIPATION *********************************************************************** 12th Information Security Conference (ISC 2009) Pisa, Italy -- September 7-9, 2009 http://isc09.dti.unimi.it *********************************************************************** ABOUT THE CONFERENCE ISC is an annual international conference covering research in and applications of information security. The twelfth Information Security Conference (ISC 2009) will be held in Pisa, Italy. The conference seeks submissions from academia, industry, and government presenting novel research on all theoretical and practical aspects of information security. The conference will be a 3-day event featuring technical presentations of 29 full papers and 9 short papers and two invited talks. The twelfth Information Security Conference (ISC 2009) will be held in Pisa, Italy. REGISTRATION Registration information is available at http://isc09.dti.unimi.it/registration PROGRAM * Monday, September 7, 2009 9:00 - 9:30 Opening 9:30 - 10:30 Keynote speaker: Prof. Sushil Jajodia 10:30 - 11:00 Coffee break 11:00 - 13:00 Session 1: Analysis techniques A New Approach to chi^2 Cryptanalysis of Block Ciphers Jorge Nakahara Jr, Gautham Sekar, Daniel Santana de Freitas, Chang Chiann, Ramon Hugo de Souza, and Bart Preneel Analysis and Optimization of Cryptographically Generated Addresses Joppe W. Bos, Onur Ozen, and Jean-Pierre Hubaux Security Analysis of the PACE Key-Agreement Protocol Jens Bender, Marc Fischlin, and Dennis Kugler Towards Security Notions for White-Box Cryptography (Short Paper) Amitabh Saxena, Brecht Wyseur, and Bart Preneel A calculus to detect guessing attacks (Short Paper) Bogdan Groza and Marius Minea 13:00 - 14:15 Lunch 14:15 - 15:45 Session 2: Hash functions Structural Attacks on Two SHA-3 Candidates: Blender-n and DCH-n Mario Lamberger and Florian Mendel Meet-in-the-Middle Attacks Using Output Truncation in 3-Pass HAVAL Yu Sasaki On Free-Start Collisions and Collisions for TIB3 Florian Mendel and Martin Schlaffer 15:45 - 16:15 Coffee break 16:15 - 17:45 Session 3: Database security and biometrics Detection of Database Intrusion using a Two-Stage Fuzzy System Suvasini Panigrahi, Shamik Sural Combining Consistency and Confidentiality Requirements in First-Order Databases Joachim Biskup and Lena Wiese Cancelable Iris Biometrics using Block Re-mapping and Image Warping (Short Paper) Jutta Hammerle-Uhl, Elias Pschernig, and Andreas Uhl Iris Recognition in Nonideal Situations (Short Paper) Kaushik Roy and Prabir Bhattacharya * Tuesday, September 8, 2009 09:00 - 10:30 Session 4: Algebraic attacks and proxy re-encryption Efficient Conditional Proxy Re-Encryption with Chosen-Ciphertext Security Jian Weng, Yanjiang Yang, Qiang Tang, Robert H. Deng, and Feng Bao Practical Algebraic Attacks on the Hitag2 Stream Cipher Nicolas T. Courtois, Sean ObNeil, and Jean-Jacques Quisquater A New Construction of Boolean Functions with Maximum Algebraic Immunity Deshuai Dong, Shaojing Fu, Longjiang Qu, and Chao Li 10:30 - 11:00 Coffee break 11:00 - 13:00 Session 5: Distributed system security A2M: Access-Assured Mobile Desktop Computing Angelos Stavrou, Ricardo A. Barrato, Angelos D. Keromytis, and Jason Nieh Automated Spyware Collection and Analysis Andreas Stamminger, Christopher Kruegel, Giovanni Vigna, and Engin Kirda Towards Unifying Vulnerability Information for Attack Graph Construction Sebastian Roschke, Feng Cheng, Robert Schuppenies, and Christoph Meinel Traitor Tracing without a Priori Bound on the Coalition Size (Short Paper) Hongxia Jin and Serdar Pehlivanoglu SISR - a New Model for Epidemic Spreading of Electronic Threats (Short Paper) Boris Rozenberg, Ehud Gudes, and Yuval Elovici 13:00 - 14:15 Lunch 14:15 - 15:45 Session 6: Identity management and authentication An Efficient Distance Bounding RFID Authentication Protocol: Balancing False-Acceptance Rate and Memory Requirement Gildas Avoine and Aslan Tchamkerten Robust Authentication Using Physically Unclonable Functions Keith B. Frikken, Marina Blanton, and Mikhail J. Atallah Risks of the CardSpace Protocol Sebastian Gajek, Jorg Schwenk, Michael Steiner, and Chen Xuan 15:45 - 16:15 Coffee break 16:15 - 18:00 Session 7: Applied cryptography Fair E-cash: Be Compact, Spend Faster Sebastien Canard, Cecile Delerablee, Aline Gouget, Emeline Hufschmitt, Fabien Laguillaumie, Herve Sibert, Jacques Traore, and Damien Vergnaud On the security of Identity Based Ring Signcryption Schemes S. Sharmila Deva Selvi, S. Sree Vivek, and C. Pandu Rangan A Storage Efficient Redactable Signature in the Standard Model Ryo Nojima, Jin Tamura, Youki Kadobayashi, and Hiroaki Kikuchi Generic Construction of Stateful Identity Based Encryption (Short Paper) Peng Yang, Rui Zhang, Kanta Matsuura, and Hideki Imai * Wednesday, September 9, 2009 09:30 - 10:30 Keynote speaker: Prof. Jan Camenisch 10:30 - 11:00 Coffee break 11:00 - 13:00 Session 8: Access control Privacy-aware Attribute-based Encryption with User Accountability Jin Li, Kui Ren, Bo Zhu, and Zhiguo Wan Hardware-Assisted Application-Level Access Control Yu-Yuan Chen and Ruby B. Lee Towards Trustworthy Delegation in Role-Based Access Control Model Manachai Toahchoodee, Xing Xie, and Indrakshi Ray Secure Interoperation in Multidomain Environments Employing UCON Policies (Short Paper) Jianfeng Lu, Ruixuan Li, Vijay Varadharajan, Zhengding Lu, and Xiaopu Ma Specification and Enforcement of Static Separation-of-Duty Policies in Usage Control (Short Paper) Jianfeng Lu, Ruixuan Li, Zhengding Lu, Jinwei Hu, and Xiaopu Ma 13:00 - 14:15 Lunch 14:15 - 15:45 Session 9: MAC and nonces Nonce Generators and the Nonce Reset Problem Erik Zenner MAC Precomputation with Applications to Secure Memory Juan Garay, Vladimir Kolesnikov, and Rae McLellan HMAC without the b Secondb Key Kan Yasuda 15:45 - 16:15 Coffee Break 16:15 - 17:45 Session 10: P2P and web services Adding Trust to P2P Distribution of Paid Content Alex Sherman, Angelos Stavrou, Jason Nieh, Angelos D. Keromytis, and Cliff Stein Peer-to-peer Architecture for Collaborative Intrusion and Malware Detection on a Large Scale Mirco Marchetti, Michele Messori, and Michele Colajanni F3ildCrypt: End-to-End Protection of Sensitive Information in Web Services Matthew Burnside and Angelos D. Keromytis MORE INFORMATION Additional information about the conference can be found at http://isc09.dti.unimi.it/ _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

FC: Why we don't use digital cash
by Declan McCullagh 05 Jul '18

05 Jul '18

[Digital cash inventor David Chaum filed for his first patent in this area on June 25, 1982. The suite begins to expire in 2002, with an important patent expiring in 2005. Seems as though we'll have to wait 'til then to see truly anonymous digital cash. For now, we're stuck with PayPal and credit cards. Sigh. --Declan] --- http://www.wired.com/news/ebiz/0,1272,44507,00.html Digging Those Digicash Blues By Declan McCullagh (declan(a)wired.com) 2:00 a.m. June 14, 2001 PDT BALTIMORE -- For the last six years, Robert Hettinga has been agitating, begging and pleading for the world to listen to his ambitious plans for digital money. Like any savvy techno-evangelist, Hettinga coined a name for his idea -- digital bearer certificates -- and envisions a day when Internet users can withdraw electronic cash by simply typing in an ATM card number and their PIN. To bolster his campaign, Hettinga launched the Digital Commerce Society of Boston, co-founded the Financial Cryptography conference, and has become a fixture on mailing lists devoted to cryptography and security. DCSB has even birthed offspring: On Tuesday, Hettinga came to Baltimore to speak at the inaugural meeting of a new sister chapter. But six years, five Financial Cryptography conferences and thousands of e-mail missives later, Hettinga has been almost entirely unsuccessful in attracting serious interest in his ideas. His two-year-old Internet Bearer Underwriting Corporation missed the ready capital of the online boom. It has attracted only $160,000 in funding, and has done about $100,000 of consulting work so far. "Quite frankly, the dot-com money has gone away," says Hettinga, 42. "We're also running over ground that CyberCash, DigiCash and a lot of other people have burned." Incinerated would be closer to the truth. The electronic cash landscape is littered with the looted corpses of companies that tried and failed to compete with credit cards for online purchases. True digital cash that's as anonymous, as privacy-protected and as cheap as the humble greenback seems to be one of those technologies that pundits laud and technologists adore, but markets stubbornly fail to adopt. [...] ------------------------------------------------------------------------- POLITECH -- Declan McCullagh's politics and technology mailing list You may redistribute this message freely if you include this notice. To subscribe, visit http://www.politechbot.com/info/subscribe.html This message is archived at http://www.politechbot.com/ ------------------------------------------------------------------------- ----- End forwarded message -----

1 0

Threats to anonymity set at and above the application layer; HTTP
by Seth David Schoen 05 Jul '18

05 Jul '18

headers User-Agent: Mutt/1.5.11 Reply-To: or-talk(a)freehaven.net It's pretty well understood that anonymity can be lost at higher protocol layers even when it's well protected at lower layers. One eye-opening paper on this point is "Can Pseudonymity Really Guarantee Privacy?" by Rao and Rohatgi (in the Freehaven Anonymity Bibliography): http://www.usenix.org/publications/library/proceedings/sec2000/full_papers/… o/rao.pdf This is a philosophically interesting problem; it prompts the question "if pseudonymity can't guarantee privacy, what _can_?". (Rao and Rohatgi remind us that the authors of the Federalist Papers used pseudonyms and were still identified solely from the evidence of their writing.) There is also the scary field of timing attacks on users' typing: http://www.cs.berkeley.edu/~daw/papers/ssh-use01.pdf http://www.cs.berkeley.edu/~tygar/papers/Keyboard_Acoustic_Emanations_Revis… ed/ccs.pdf (The Tygar paper is not really relevant for network surveillance, but it shows the scariness of statistical methods for figuring out what users are doing based on seemingly irrelevant information.) In a sense, there are many privacy-threatening features in and above the application layer (some of them depending on the nature and latency of a communication): * timing of access (what time zone are you in, when do you usually do something?) -- for communications with non-randomized latency < 1 day * typing patterns (cf. Cliff Stoll's _Cuckoo's Egg_ and the Song et al. paper) * typing speed * language comprehension and selection * language proficiency * idiosyncratic language use * idiosyncratic language errors (cf. Rao and Rohatgi) * cookies and their equivalents (cf. Martin Pool's "meantime", a cookie equivalent using client-side information that was intended for a totally different purpose -- cache control) * unique browser or other application headers or behavior (distinguishing MSIE from Firefox from Opera? not just based on User-agent but based on request patterns, e.g. for inline images, and different interpretations of HTTP standards and perhaps CSS and JavaScript standards) * different user-agent versions (including leaked information about the platform) * different privoxy versions and configurations I'm not sure what to do to mitigate these things. The Rao paper alone strongly suggests that providing privacy up to the application layer will not always make communications unlinkable (and then there is the problem of insulating what pseudonymous personae are supposed to know about or not know about, and the likelihood of correlations between things they mention). These problems are alluded to in on the Tor web site: Tor can't solve all anonymity problems. It focuses only on protecting the transport of data. You need to use protocol-specific support software if you don't want the sites you visit to see your identifying information. For example, you can use web proxies such as Privoxy while web browsing to block cookies and withhold information about your browser type. Also, to protect your anonymity, be smart. Don't provide your name or other revealing information in web forms. Be aware that, like all anonymizing networks that are fast enough for web browsing, Tor does not provide protection against end-to-end timing attacks: If your attacker can watch the traffic coming out of your computer, and also the traffic arriving at your chosen destination, he can use statistical analysis to discover that they are part of the same circuit. However, the recommendation to use Privoxy, by itself, is far from solving the problem of correlations between user and user sessions. I think a low-hanging target is the uniqueness of HTTP headers sent by particular users of HTTP and HTTPS over Tor. Accept-Language, User-Agent, and a few browser-specific features are likely to reveal locale and OS and browser version -- sometimes relatively uniquely, as when someone uses a Linux distribution that ships with a highly specific build of Firefox -- and this combination may serve to make people linkable or distinguishable in particular contexts. Privoxy does _not_, depending on its configuration, necessarily remove or rewrite all of the potentially relevant HTTP protocol headers. Worse, different Privoxy configurations may actually introduce _new_ headers or behaviors that further serve to differentiate users from one another. One example is that some Privoxy configurations insert headers specifically identifying the user as a Privoxy user and taunting the server operator; but if some users do this and other users don't, the anonymity set is chopped up into lots of little bitty anonymity sets. For instance: +add-header{X-User-Tracking: sucks} User tracking does suck, but adding an optional header saying so has the obvious effect of splitting the anonymity set in some circumstances into people who send the X-User-Tracking: sucks header and people who don't. Any variation in practice here is potentially bad for the size of the anonymity set. A remedy for this would be to try to create a standardized Privoxy configuration and set of browser headers, and then try to convince as many Tor users as possible to use that particular configuration. (One way to do this is to try to convince everyone who makes a Tor+Privoxy distribution or product to use the agreed-upon default configuration.) The goal is not to prevent people from controlling their own Privoxy configurations or doing more things to protect their privacy; rather, it is to try to reduce the variety in headers and behaviors seen by web servers contacted by Tor users on different platforms. -- Seth Schoen Staff Technologist schoen(a)eff.org Electronic Frontier Foundation http://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 1 415 436 9333 x107 ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [cryptography] anyone got a "how not to use OpenSSL" list?
by Aaron Grattafiori 05 Jul '18

05 Jul '18

While more "proper" uses of OpenSSL vs improper, participates of the discussion might enjoy the following whitepaper and tool release by iSEC Partners and an Academic look at popular non-browser SSL failures (bottom): https://www.isecpartners.com/blog/2012/10/14/the-lurking-menace-of-broken-t… "Everything Youbve Always Wanted to Know About Certificate Validation With OpenSSL": https://www.isecpartners.com/storage/files/everything-you-wanted-to-know-ab… "TLSPretense is a tool for testing certificate and hostname validation as part of an TLS/SSL connection" https://github.com/iSECPartners/tlspretense This was released in tandem with Dan Boneh, M. Georgiev, S. Iyengar, S. Jana, R. Anubhai's SSL paper: "The most dangerous code in the world: validating SSL certificates in non-browser software": https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html -Aaron On Wed, Oct 24, 2012 at 8:41 PM, Jeffrey Walton <noloader(a)gmail.com> wrote: > On Wed, Oct 10, 2012 at 1:34 PM, > <travis+ml-rbcryptography(a)subspacefield.org> wrote: >> I want to find common improper usages of OpenSSL library for SSL/TLS. >> >> Can be reverse-engineered from a "how to properly use OpenSSL" FAQ, >> probably, but would prefer information to the first point rather than >> its complement. >> -- >> http://www.subspacefield.org/~travis/ > Calling RAND_pseudo_bytes instead of RAND_bytes. To make matters > worst, they return slightly different values - 0 means failure for > RAND_bytes; while 0 means "non-cryptographic bytes have been returned" > for RAND_pseudo_bytes. > _______________________________________________ > cryptography mailing list > cryptography(a)randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [drone-list] Using UAVs in Humanitarian Crises to Restore Connectivity
by The Doctor 05 Jul '18

05 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/2012 07:34 AM, Joseph Pollack wrote: > I'm looking into how tough and expensive and illegal it would be to > use DIY or low-cost UAVs to restore connectivity or "gather" > messages (SOS or otherwise) from populations affected by > humanitarian crises. Any thoughts or suggestions? Looking at the illegal bit first, if somewhere is in bad enough shape that you have to set up a guerilla communications network to assist in disaster relief, chances are you've got a pretty good leg to stand on. IANAL, call your own, #include <std/disclaimer.h> That said, it's something a few of us have worked on. There are a couple of drones that are relatively low cost (most of them quadcopters) that appear to have enough lift to transport small mesh nodes for short distances and perch someplace to conserve motor power. The 3d printed quadcopters that Telecomix were examining might work for this purpose (http://www.thingiverse.com/thing:17612) To my knowledge, we haven't examined this one (http://www.thingiverse.com/thing:22537) closely because I haven't had time to spend on HacDC's 3D printers. For both models, the possibility of using hacked Android devices for the network nodes themselves came up a number of times. There is also a hacker working on porting Byzantium Linux to the ARM platform, because he wants to try it on the RaspberryPi. We don't know where he's at with that project right now. It should also be relatively easy to repurpose a more conventional model craft (like the toy quadcopters resembling Thingiverse entry #22537 above) into mobility platforms for mesh nodes. So long as the network node had sufficient power (I kind of like the idea of the solar charger in an envelope kits that were going around at HOPE9 - I forget who manufactured them but they're cheap and designed to be used as trickle chargers) for wireless and the motors of the drone could be shut down to conserve their power cells, the keys would be positioning and stability of perch. - -- The Doctor [412/724/301/703] [ZS (MED)] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ If patience is bitter, the result is sweet. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlC+LKwACgkQO9j/K4B7F8E0yQCgq0P9VS9h4EsaWcB990fy576E vcsAnRtA6ARe5ftIO0sxJECc2AdyJ5jh =nCFc -----END PGP SIGNATURE----- _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Fwd: HiveCache - P2P Backups
by Fearghas McKay 05 Jul '18

05 Jul '18

--- begin forwarded text From: Peter Gradwell <peter(a)gradwell.com> (by way of Fearghas McKay <fm-news123(a)st-kilda.org>) To: fm(a)espace.net Subject: HiveCache - P2P Backups Date: Tue, 21 Jan 2003 14:04:35 -0800 Hello Apologies for the intrusion. As well has running an ISP, I have an interest in Grid Computing systems and micro accounting architectures. As part of the interest, I would like to deploy a product called HiveCache (www.hivecache.com) to my customer base, and others interested. HiveCache is a p2p backup system where by you define an amount of disk space available on your machine (which is connected via broadband of course!) and vice versa, your files get split up, encrypted and then stored on everyone elses' disk space. HiveCache does all sorts of clever things, like making sure enough copies are kept in various places, files are split & encrypted, allowing you to retrieve them, etc. Ultimately, I would like to faciliate a system where by we act as a clearing house so that users can buy & sell disk space & resources. In order to get going however, I would like to take part in the HiveCache pilot. To do this, I require 25-50 willing volunteers. You will need: - an always on broadband connection - a few gig of spare disk space - a little enthusiasm and a willingness to return comments If that sounds like you, then please could you drop an email to hivecache(a)gradwell.net stating your - name, - email, - type of internet connection and - what operating system you're running on. Any questions, let me know. many thanks peter -- peter gradwell. gradwell dot com Ltd. http://www.gradwell.com/ engineering & hosting services for email, web and usenet --- end forwarded text --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

None
by John F. McMullen 05 Jul '18

05 Jul '18

<USAtalk(a)yahoogroups.com>, Dewayne Hendricks <dewayne(a)warpspeed.com> Subject: White House Proposal Would Expand Authority of Military Courts (johnmac --I find the following to be extremely troubling -- The plan .. would also allow the secretary of defense to add crimes at will to those under the military court's jurisdiction." What "crimes"? Burning the flag? Spitting on the Sidewalk? This is, IMNSHO, a subversion of the cConstitution) >From the Washington Post -- http://www.washingtonpost.com/wp-dyn/ content/article/2006/08/01/AR2006080101334.html?nav=hcmodule White House Proposal Would Expand Authority of Military Courts By R. Jeffrey Smith A draft Bush administration plan for special military courts seeks to expand the reach and authority of such "commissions" to include trials, for the first time, of people who are not members of al-Qaeda or the Taliban and are not directly involved in acts of international terrorism, according to officials familiar with the proposal. The plan, which would replace a military trial system ruled illegal by the Supreme Court in June, would also allow the secretary of defense to add crimes at will to those under the military court's jurisdiction. The two provisions would be likely to put more individuals than previously expected before military juries, officials and independent experts said. The draft proposed legislation, set to be discussed at two Senate hearings today, is controversial inside and outside the administration because defendants would be denied many protections guaranteed by the civilian and traditional military criminal justice systems. Under the proposed procedures, defendants would lack rights to confront accusers, exclude hearsay accusations, or bar evidence obtained through rough or coercive interrogations. They would not be guaranteed a public or speedy trial and would lack the right to choose their military counsel, who in turn would not be guaranteed equal access to evidence held by prosecutors. Detainees would also not be guaranteed the right to be present at their own trials, if their absence is deemed necessary to protect national security or individuals. An early draft of the new measure prepared by civilian political appointees and leaked to the media last week has been modified in response to criticism from uniformed military lawyers. But the provisions allowing a future expansion of the courts to cover new crimes and more prisoners were retained, according to government officials familiar with the deliberations. ... ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] White House Proposal Would Expand Authority of Military Courts
by David Farber 05 Jul '18

05 Jul '18

Begin forwarded message:

1 0

Tor 0.1.2.13 is released
by Roger Dingledine 05 Jul '18

05 Jul '18

Tor 0.1.2.13, the first stable release of the 0.1.2.x branch, is finally ready. This release features some major anonymity fixes, such as safer path selection; better client performance; faster bootstrapping, better address detection, and better DNS support for servers; write limiting as well as read limiting to make servers easier to run; and a huge pile of other features and bug fixes. The bundles also ship with Vidalia 0.0.11. https://tor.eff.org/download.html Tor 0.1.2.13 is released in memory of Rob Levin (1955-2006), aka lilo of the Freenode IRC network, remembering his patience and vision for free speech on the Internet. Changes in version 0.1.2.13 - 2007-04-24 o Major features, client performance: - Weight directory requests by advertised bandwidth. Now we can let servers enable write limiting but still allow most clients to succeed at their directory requests. (We still ignore weights when choosing a directory authority; I hope this is a feature.) - Stop overloading exit nodes -- avoid choosing them for entry or middle hops when the total bandwidth available from non-exit nodes is much higher than the total bandwidth available from exit nodes. - Rather than waiting a fixed amount of time between retrying application connections, we wait only 10 seconds for the first, 10 seconds for the second, and 15 seconds for each retry after that. Hopefully this will improve the expected user experience. - Sometimes we didn't bother sending a RELAY_END cell when an attempt to open a stream fails; now we do in more cases. This should make clients able to find a good exit faster in some cases, since unhandleable requests will now get an error rather than timing out. o Major features, client functionality: - Implement BEGIN_DIR cells, so we can connect to a directory server via TLS to do encrypted directory requests rather than plaintext. Enable via the TunnelDirConns and PreferTunneledDirConns config options if you like. For now, this feature only works if you already have a descriptor for the destination dirserver. - Add support for transparent application connections: this basically bundles the functionality of trans-proxy-tor into the Tor mainline. Now hosts with compliant pf/netfilter implementations can redirect TCP connections straight to Tor without diverting through SOCKS. (Based on patch from tup.) - Add support for using natd; this allows FreeBSDs earlier than 5.1.2 to have ipfw send connections through Tor without using SOCKS. (Patch from Zajcev Evgeny with tweaks from tup.) o Major features, servers: - Setting up a dyndns name for your server is now optional: servers with no hostname or IP address will learn their IP address by asking the directory authorities. This code only kicks in when you would normally have exited with a "no address" error. Nothing's authenticated, so use with care. - Directory servers now spool server descriptors, v1 directories, and v2 networkstatus objects to buffers as needed rather than en masse. They also mmap the cached-routers files. These steps save lots of memory. - Stop requiring clients to have well-formed certificates, and stop checking nicknames in certificates. (Clients have certificates so that they can look like Tor servers, but in the future we might want to allow them to look like regular TLS clients instead. Nicknames in certificates serve no purpose other than making our protocol easier to recognize on the wire.) Implements proposal 106. o Improvements on DNS support: - Add "eventdns" asynchronous dns library originally based on code from Adam Langley. Now we can discard the old rickety dnsworker concept, and support a wider variety of DNS functions. Allows multithreaded builds on NetBSD and OpenBSD again. - Add server-side support for "reverse" DNS lookups (using PTR records so clients can determine the canonical hostname for a given IPv4 address). Only supported by servers using eventdns; servers now announce in their descriptors if they don't support eventdns. - Workaround for name servers (like Earthlink's) that hijack failing DNS requests and replace the no-such-server answer with a "helpful" redirect to an advertising-driven search portal. Also work around DNS hijackers who "helpfully" decline to hijack known-invalid RFC2606 addresses. Config option "ServerDNSDetectHijacking 0" lets you turn it off. - Servers now check for the case when common DNS requests are going to wildcarded addresses (i.e. all getting the same answer), and change their exit policy to reject *:* if it's happening. - When asked to resolve a hostname, don't use non-exit servers unless requested to do so. This allows servers with broken DNS to be useful to the network. - Start passing "ipv4" hints to getaddrinfo(), so servers don't do useless IPv6 DNS resolves. - Specify and implement client-side SOCKS5 interface for reverse DNS lookups (see doc/socks-extensions.txt). Also cache them. - When we change nameservers or IP addresses, reset and re-launch our tests for DNS hijacking. o Improvements on reachability testing: - Servers send out a burst of long-range padding cells once they've established that they're reachable. Spread them over 4 circuits, so hopefully a few will be fast. This exercises bandwidth and bootstraps them into the directory more quickly. - When we find our DirPort to be reachable, publish a new descriptor so we'll tell the world (reported by pnx). - Directory authorities now only decide that routers are reachable if their identity keys are as expected. - Do DirPort reachability tests less often, since a single test chews through many circuits before giving up. - Avoid some false positives during reachability testing: don't try to test via a server that's on the same /24 network as us. - Start publishing one minute or so after we find our ORPort to be reachable. This will help reduce the number of descriptors we have for ourselves floating around, since it's quite likely other things (e.g. DirPort) will change during that minute too. - Routers no longer try to rebuild long-term connections to directory authorities, and directory authorities no longer try to rebuild long-term connections to all servers. We still don't hang up connections in these two cases though -- we need to look at it more carefully to avoid flapping, and we likely need to wait til 0.1.1.x is obsolete. o Improvements on rate limiting: - Enable write limiting as well as read limiting. Now we sacrifice capacity if we're pushing out lots of directory traffic, rather than overrunning the user's intended bandwidth limits. - Include TLS overhead when counting bandwidth usage; previously, we would count only the bytes sent over TLS, but not the bytes used to send them. - Servers decline directory requests much more aggressively when they're low on bandwidth. Otherwise they end up queueing more and more directory responses, which can't be good for latency. - But never refuse directory requests from local addresses. - Be willing to read or write on local connections (e.g. controller connections) even when the global rate limiting buckets are empty. - Flush local controller connection buffers periodically as we're writing to them, so we avoid queueing 4+ megabytes of data before trying to flush. - Revise and clean up the torrc.sample that we ship with; add a section for BandwidthRate and BandwidthBurst. o Major features, NT services: - Install as NT_AUTHORITY\LocalService rather than as SYSTEM; add a command-line flag so that admins can override the default by saying "tor --service install --user "SomeUser"". This will not affect existing installed services. Also, warn the user that the service will look for its configuration file in the service user's %appdata% directory. (We can't do the "hardwire the user's appdata directory" trick any more, since we may not have read access to that directory.) - Support running the Tor service with a torrc not in the same directory as tor.exe and default to using the torrc located in the %appdata%\Tor\ of the user who installed the service. Patch from Matt Edman. - Add an --ignore-missing-torrc command-line option so that we can get the "use sensible defaults if the configuration file doesn't exist" behavior even when specifying a torrc location on the command line. - When stopping an NT service, wait up to 10 sec for it to actually stop. (Patch from Matt Edman; resolves bug 295.) o Directory authority improvements: - Stop letting hibernating or obsolete servers affect uptime and bandwidth cutoffs. - Stop listing hibernating servers in the v1 directory. - Authorities no longer recommend exits as guards if this would shift too much load to the exit nodes. - Authorities now specify server versions in networkstatus. This adds about 2% to the size of compressed networkstatus docs, and allows clients to tell which servers support BEGIN_DIR and which don't. The implementation is forward-compatible with a proposed future protocol version scheme not tied to Tor versions. - DirServer configuration lines now have an orport= option so clients can open encrypted tunnels to the authorities without having downloaded their descriptors yet. Enabled for moria1, moria2, tor26, and lefkada now in the default configuration. - Add a BadDirectory flag to network status docs so that authorities can (eventually) tell clients about caches they believe to be broken. Not used yet. - Allow authorities to list nodes as bad exits in their approved-routers file by fingerprint or by address. If most authorities set a BadExit flag for a server, clients don't think of it as a general-purpose exit. Clients only consider authorities that advertise themselves as listing bad exits. - Patch from Steve Hildrey: Generate network status correctly on non-versioning dirservers. - Have directory authorities allow larger amounts of drift in uptime without replacing the server descriptor: previously, a server that restarted every 30 minutes could have 48 "interesting" descriptors per day. - Reserve the nickname "Unnamed" for routers that can't pick a hostname: any router can call itself Unnamed; directory authorities will never allocate Unnamed to any particular router; clients won't believe that any router is the canonical Unnamed. o Directory mirrors and clients: - Discard any v1 directory info that's over 1 month old (for directories) or over 1 week old (for running-routers lists). - Clients track responses with status 503 from dirservers. After a dirserver has given us a 503, we try not to use it until an hour has gone by, or until we have no dirservers that haven't given us a 503. - When we get a 503 from a directory, and we're not a server, we no longer count the failure against the total number of failures allowed for the object we're trying to download. - Prepare for servers to publish descriptors less often: never discard a descriptor simply for being too old until either it is recommended by no authorities, or until we get a better one for the same router. Make caches consider retaining old recommended routers for even longer. - Directory servers now provide 'Pragma: no-cache' and 'Expires' headers for content, so that we can work better in the presence of caching HTTP proxies. - Stop fetching descriptors if you're not a dir mirror and you haven't tried to establish any circuits lately. (This currently causes some dangerous behavior, because when you start up again you'll use your ancient server descriptors.) o Major fixes, crashes: - Stop crashing when the controller asks us to resetconf more than one config option at once. (Vidalia 0.0.11 does this.) - Fix a longstanding obscure crash bug that could occur when we run out of DNS worker processes, if we're not using eventdns. (Resolves bug 390.) - Fix an assert that could trigger if a controller quickly set then cleared EntryNodes. (Bug found by Udo van den Heuvel.) - Avoid crash when telling controller about stream-status and a stream is detached. - Avoid sending junk to controllers or segfaulting when a controller uses EVENT_NEW_DESC with verbose nicknames. - Stop triggering asserts if the controller tries to extend hidden service circuits (reported by mwenge). - If we start a server with ClientOnly 1, then set ClientOnly to 0 and hup, stop triggering an assert based on an empty onion_key. - Mask out all signals in sub-threads; only the libevent signal handler should be processing them. This should prevent some crashes on some machines using pthreads. (Patch from coderman.) - Disable kqueue on OS X 10.3 and earlier, to fix bug 371. o Major fixes, anonymity/security: - Automatically avoid picking more than one node from the same /16 network when constructing a circuit. Add an "EnforceDistinctSubnets" option to let people disable it if they want to operate private test networks on a single subnet. - When generating bandwidth history, round down to the nearest 1k. When storing accounting data, round up to the nearest 1k. - When we're running as a server, remember when we last rotated onion keys, so that we will rotate keys once they're a week old even if we never stay up for a week ourselves. - If a client asked for a server by name, and there's a named server in our network-status but we don't have its descriptor yet, we could return an unnamed server instead. - Reject (most) attempts to use Tor circuits with length one. (If many people start using Tor as a one-hop proxy, exit nodes become a more attractive target for compromise.) - Just because your DirPort is open doesn't mean people should be able to remotely teach you about hidden service descriptors. Now only accept rendezvous posts if you've got HSAuthoritativeDir set. - Fix a potential race condition in the rpm installer. Found by Stefan Nordhausen. - Do not log IPs with TLS failures for incoming TLS connections. (Fixes bug 382.) o Major fixes, other: - If our system clock jumps back in time, don't publish a negative uptime in the descriptor. - When we start during an accounting interval before it's time to wake up, remember to wake up at the correct time. (May fix bug 342.) - Previously, we would cache up to 16 old networkstatus documents indefinitely, if they came from nontrusted authorities. Now we discard them if they are more than 10 days old. - When we have a state file we cannot parse, tell the user and move it aside. Now we avoid situations where the user starts Tor in 1904, Tor writes a state file with that timestamp in it, the user fixes her clock, and Tor refuses to start. - Publish a new descriptor after we hup/reload. This is important if our config has changed such that we'll want to start advertising our DirPort now, etc. - If we are using an exit enclave and we can't connect, e.g. because its webserver is misconfigured to not listen on localhost, then back off and try connecting from somewhere else before we fail. o New config options or behaviors: - When EntryNodes are configured, rebuild the guard list to contain, in order: the EntryNodes that were guards before; the rest of the EntryNodes; the nodes that were guards before. - Do not warn when individual nodes in the configuration's EntryNodes, ExitNodes, etc are down: warn only when all possible nodes are down. (Fixes bug 348.) - Put a lower-bound on MaxAdvertisedBandwidth. - Start using the state file to store bandwidth accounting data: the bw_accounting file is now obsolete. We'll keep generating it for a while for people who are still using 0.1.2.4-alpha. - Try to batch changes to the state file so that we do as few disk writes as possible while still storing important things in a timely fashion. - The state file and the bw_accounting file get saved less often when the AvoidDiskWrites config option is set. - Make PIDFile work on Windows. - Add internal descriptions for a bunch of configuration options: accessible via controller interface and in comments in saved options files. - Reject *:563 (NNTPS) in the default exit policy. We already reject NNTP by default, so this seems like a sensible addition. - Clients now reject hostnames with invalid characters. This should avoid some inadvertent info leaks. Add an option AllowNonRFC953Hostnames to disable this behavior, in case somebody is running a private network with hosts called @, !, and #. - Check for addresses with invalid characters at the exit as well, and warn less verbosely when they fail. You can override this by setting ServerDNSAllowNonRFC953Addresses to 1. - Remove some options that have been deprecated since at least 0.1.0.x: AccountingMaxKB, LogFile, DebugLogFile, LogLevel, and SysLog. Use AccountingMax instead of AccountingMaxKB, and use Log to set log options. Mark PathlenCoinWeight as obsolete. - Stop accepting certain malformed ports in configured exit policies. - When the user uses bad syntax in the Log config line, stop suggesting other bad syntax as a replacement. - Add new config option "ResolvConf" to let the server operator choose an alternate resolve.conf file when using eventdns. - If one of our entry guards is on the ExcludeNodes list, or the directory authorities don't think it's a good guard, treat it as if it were unlisted: stop using it as a guard, and throw it off the guards list if it stays that way for a long time. - Allow directory authorities to be marked separately as authorities for the v1 directory protocol, the v2 directory protocol, and as hidden service directories, to make it easier to retire old authorities. V1 authorities should set "HSAuthoritativeDir 1" to continue being hidden service authorities too. - Remove 8888 as a LongLivedPort, and add 6697 (IRCS). - Make TrackExitHosts case-insensitive, and fix the behavior of ".suffix" TrackExitHosts items to avoid matching in the middle of an address. - New DirPort behavior: if you have your dirport set, you download descriptors aggressively like a directory mirror, whether or not your ORPort is set. o Docs: - Create a new file ReleaseNotes which was the old ChangeLog. The new ChangeLog file now includes the notes for all development versions too. - Add a new address-spec.txt document to describe our special-case addresses: .exit, .onion, and .noconnnect. - Fork the v1 directory protocol into its own spec document, and mark dir-spec.txt as the currently correct (v2) spec. o Packaging, porting, and contrib - "tor --verify-config" now exits with -1(255) or 0 depending on whether the config options are bad or good. - The Debian package now uses --verify-config when (re)starting, to distinguish configuration errors from other errors. - Adapt a patch from goodell to let the contrib/exitlist script take arguments rather than require direct editing. - Prevent the contrib/exitlist script from printing the same result more than once. - Add support to tor-resolve tool for reverse lookups and SOCKS5. - In the hidden service example in torrc.sample, stop recommending esoteric and discouraged hidden service options. - Patch from Michael Mohr to contrib/cross.sh, so it checks more values before failing, and always enables eventdns. - Try to detect Windows correctly when cross-compiling. - Libevent-1.2 exports, but does not define in its headers, strlcpy. Try to fix this in configure.in by checking for most functions before we check for libevent. - Update RPMs to require libevent 1.2. - Experimentally re-enable kqueue on OSX when using libevent 1.1b or later. Log when we are doing this, so we can diagnose it when it fails. (Also, recommend libevent 1.1b for kqueue and win32 methods; deprecate libevent 1.0b harder; make libevent recommendation system saner.) - Build with recent (1.3+) libevents on platforms that do not define the nonstandard types "u_int8_t" and friends. - Remove architecture from OS X builds. The official builds are now universal binaries. - Run correctly on OS X platforms with case-sensitive filesystems. - Correctly set maximum connection limit on Cygwin. (This time for sure!) - Start compiling on MinGW on Windows (patches from Mike Chiussi and many others). - Start compiling on MSVC6 on Windows (patches from Frediano Ziglio). - Finally fix the openssl warnings from newer gccs that believe that ignoring a return value is okay, but casting a return value and then ignoring it is a sign of madness. - On architectures where sizeof(int)>4, still clamp declarable bandwidth to INT32_MAX. o Minor features, controller: - Warn the user when an application uses the obsolete binary v0 control protocol. We're planning to remove support for it during the next development series, so it's good to give people some advance warning. - Add STREAM_BW events to report per-entry-stream bandwidth use. (Patch from Robert Hogan.) - Rate-limit SIGNEWNYM signals in response to controllers that impolitely generate them for every single stream. (Patch from mwenge; closes bug 394.) - Add a REMAP status to stream events to note that a stream's address has changed because of a cached address or a MapAddress directive. - Make REMAP stream events have a SOURCE (cache or exit), and make them generated in every case where we get a successful connected or resolved cell. - Track reasons for OR connection failure; make these reasons available via the controller interface. (Patch from Mike Perry.) - Add a SOCKS_BAD_HOSTNAME client status event so controllers can learn when clients are sending malformed hostnames to Tor. - Specify and implement some of the controller status events. - Have GETINFO dir/status/* work on hosts with DirPort disabled. - Reimplement GETINFO so that info/names stays in sync with the actual keys. - Implement "GETINFO fingerprint". - Implement "SETEVENTS GUARD" so controllers can get updates on entry guard status as it changes. - Make all connections to addresses of the form ".noconnect" immediately get closed. This lets application/controller combos successfully test whether they're talking to the same Tor by watching for STREAM events. - Add a REASON field to CIRC events; for backward compatibility, this field is sent only to controllers that have enabled the extended event format. Also, add additional reason codes to explain why a given circuit has been destroyed or truncated. (Patches from Mike Perry) - Add a REMOTE_REASON field to extended CIRC events to tell the controller why a remote OR told us to close a circuit. - Stream events also now have REASON and REMOTE_REASON fields, working much like those for circuit events. - There's now a GETINFO ns/... field so that controllers can ask Tor about the current status of a router. - A new event type "NS" to inform a controller when our opinion of a router's status has changed. - Add a GETINFO events/names and GETINFO features/names so controllers can tell which events and features are supported. - A new CLEARDNSCACHE signal to allow controllers to clear the client-side DNS cache without expiring circuits. - Fix CIRC controller events so that controllers can learn the identity digests of non-Named servers used in circuit paths. - Let controllers ask for more useful identifiers for servers. Instead of learning identity digests for un-Named servers and nicknames for Named servers, the new identifiers include digest, nickname, and indication of Named status. Off by default; see control-spec.txt for more information. - Add a "getinfo address" controller command so it can display Tor's best guess to the user. - New controller event to alert the controller when our server descriptor has changed. - Give more meaningful errors on controller authentication failure. - Export the default exit policy via the control port, so controllers don't need to guess what it is / will be later. o Minor bugfixes, controller: - When creating a circuit via the controller, send a 'launched' event when we're done, so we follow the spec better. - Correct the control spec to match how the code actually responds to 'getinfo addr-mappings/*'. Reported by daejees. - The control spec described a GUARDS event, but the code implemented a GUARD event. Standardize on GUARD, but let people ask for GUARDS too. Reported by daejees. - Give the controller END_STREAM_REASON_DESTROY events _before_ we clear the corresponding on_circuit variable, and remember later that we don't need to send a redundant CLOSED event. (Resolves part 3 of bug 367.) - Report events where a resolve succeeded or where we got a socks protocol error correctly, rather than calling both of them "INTERNAL". - Change reported stream target addresses to IP consistently when we finally get the IP from an exit node. - Send log messages to the controller even if they happen to be very long. - Flush ERR-level controller status events just like we currently flush ERR-level log events, so that a Tor shutdown doesn't prevent the controller from learning about current events. - Report the circuit number correctly in STREAM CLOSED events. Bug reported by Mike Perry. - Do not report bizarre values for results of accounting GETINFOs when the last second's write or read exceeds the allotted bandwidth. - Report "unrecognized key" rather than an empty string when the controller tries to fetch a networkstatus that doesn't exist. - When the controller does a "GETINFO network-status", tell it about even those routers whose descriptors are very old, and use long nicknames where appropriate. - Fix handling of verbose nicknames with ORCONN controller events: make them show up exactly when requested, rather than exactly when not requested. - Controller signals now work on non-Unix platforms that don't define SIGUSR1 and SIGUSR2 the way we expect. - Respond to SIGNAL command before we execute the signal, in case the signal shuts us down. Suggested by Karsten Loesing. - Handle reporting OR_CONN_EVENT_NEW events to the controller. o Minor features, code performance: - Major performance improvement on inserting descriptors: change algorithm from O(n^2) to O(n). - Do not rotate onion key immediately after setting it for the first time. - Call router_have_min_dir_info half as often. (This is showing up in some profiles, but not others.) - When using GCC, make log_debug never get called at all, and its arguments never get evaluated, when no debug logs are configured. (This is showing up in some profiles, but not others.) - Statistics dumped by -USR2 now include a breakdown of public key operations, for profiling. - Make the common memory allocation path faster on machines where malloc(0) returns a pointer. - Split circuit_t into origin_circuit_t and or_circuit_t, and split connection_t into edge, or, dir, control, and base structs. These will save quite a bit of memory on busy servers, and they'll also help us track down bugs in the code and bugs in the spec. - Use OpenSSL's AES implementation on platforms where it's faster. This could save us as much as 10% CPU usage. o Minor features, descriptors and descriptor handling: - Avoid duplicate entries on MyFamily line in server descriptor. - When Tor receives a router descriptor that it asked for, but no longer wants (because it has received fresh networkstatuses in the meantime), do not warn the user. Cache the descriptor if we're a cache; drop it if we aren't. - Servers no longer ever list themselves in their "family" line, even if configured to do so. This makes it easier to configure family lists conveniently. o Minor fixes, confusing/misleading log messages: - Display correct results when reporting which versions are recommended, and how recommended they are. (Resolves bug 383.) - Inform the server operator when we decide not to advertise a DirPort due to AccountingMax enabled or a low BandwidthRate. - Only include function names in log messages for info/debug messages. For notice/warn/err, the content of the message should be clear on its own, and printing the function name only confuses users. - Remove even more protocol-related warnings from Tor server logs, such as bad TLS handshakes and malformed begin cells. - Fix bug 314: Tor clients issued "unsafe socks" warnings even when the IP address is mapped through MapAddress to a hostname. - Fix misleading log messages: an entry guard that is "unlisted", as well as not known to be "down" (because we've never heard of it), is not therefore "up". o Minor fixes, old/obsolete behavior: - Start assuming we can use a create_fast cell if we don't know what version a router is running. - We no longer look for identity and onion keys in "identity.key" and "onion.key" -- these were replaced by secret_id_key and secret_onion_key in 0.0.8pre1. - We no longer require unrecognized directory entries to be preceded by "opt". - Drop compatibility with obsolete Tors that permit create cells to have the wrong circ_id_type. - Remove code to special-case "-cvs" ending, since it has not actually mattered since 0.0.9. - Don't re-write the fingerprint file every restart, unless it has changed. o Minor fixes, misc client-side behavior: - Always remove expired routers and networkstatus docs before checking whether we have enough information to build circuits. (Fixes bug 373.) - When computing clock skew from directory HTTP headers, consider what time it was when we finished asking for the directory, not what time it is now. - Make our socks5 handling more robust to broken socks clients: throw out everything waiting on the buffer in between socks handshake phases, since they can't possibly (so the theory goes) have predicted what we plan to respond to them. - Expire socks connections if they spend too long waiting for the handshake to finish. Previously we would let them sit around for days, if the connecting application didn't close them either. - And if the socks handshake hasn't started, don't send a "DNS resolve socks failed" handshake reply; just close it. - If the user asks to use invalid exit nodes, be willing to use unstable ones. - Track unreachable entry guards correctly: don't conflate 'unreachable by us right now' with 'listed as down by the directory authorities'. With the old code, if a guard was unreachable by us but listed as running, it would clog our guard list forever. - Behave correctly in case we ever have a network with more than 2GB/s total advertised capacity. - Claim a commonname of Tor, rather than TOR, in TLS handshakes. - Fix a memory leak when we ask for "all" networkstatuses and we get one we don't recognize. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Fwd: HiveCache - P2P Backups
by Fearghas McKay 05 Jul '18

05 Jul '18

--- begin forwarded text From: Peter Gradwell <peter(a)gradwell.com> (by way of Fearghas McKay <fm-news123(a)st-kilda.org>) To: fm(a)espace.net Subject: HiveCache - P2P Backups Date: Tue, 21 Jan 2003 14:04:35 -0800 Hello Apologies for the intrusion. As well has running an ISP, I have an interest in Grid Computing systems and micro accounting architectures. As part of the interest, I would like to deploy a product called HiveCache (www.hivecache.com) to my customer base, and others interested. HiveCache is a p2p backup system where by you define an amount of disk space available on your machine (which is connected via broadband of course!) and vice versa, your files get split up, encrypted and then stored on everyone elses' disk space. HiveCache does all sorts of clever things, like making sure enough copies are kept in various places, files are split & encrypted, allowing you to retrieve them, etc. Ultimately, I would like to faciliate a system where by we act as a clearing house so that users can buy & sell disk space & resources. In order to get going however, I would like to take part in the HiveCache pilot. To do this, I require 25-50 willing volunteers. You will need: - an always on broadband connection - a few gig of spare disk space - a little enthusiasm and a willingness to return comments If that sounds like you, then please could you drop an email to hivecache(a)gradwell.net stating your - name, - email, - type of internet connection and - what operating system you're running on. Any questions, let me know. many thanks peter -- peter gradwell. gradwell dot com Ltd. http://www.gradwell.com/ engineering & hosting services for email, web and usenet --- end forwarded text --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0