July 2018 - cypherpunks-legacy

[DIYbio] Re: Lethal Bird Flu Transmission Among Humans Now Possible Thanks to Biochemists
by EJ 06 Jul '18

06 Jul '18

According to articles in Nature and Science, the thing that tipped the scales in favor of publication was the discovery of natural flu variants that were halfway towards the full complement of mutations necessary for increased transmission. That supported the argument that such research could help predict what variants should be carefully monitored. -- You received this message because you are subscribed to the Google Groups "DIYbio" group. To view this discussion on the web visit https://groups.google.com/d/msg/diybio/-/xIuTf6sHsHUJ. To post to this group, send email to diybio(a)googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/diybio?hl=en. ----- 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

[p2p-hackers] Re: anon-layer comparison
by Euseval＠aol.com 06 Jul '18

06 Jul '18

jetiants http://www.jetiants.tk Gnu-net http://www.ovmj.org/GNUnet/ I2p http://www.i2p.net/ Tor http://freehaven.net/tor/ These may be naive questions (I don't know GNUnet too well), but > hopefully I am about to learn something: GNUnet tries to achieve at > least three goals at the same time that are not perfectly understood > and should rather be treated individually: > > - anonymity > - censor resistance > - high-performance document distribution Performance is a secondary goal to the first 2 in GNUnet. The first 2 are related so I'm not sure how or why they need to be treated separately. > Also, don't the shortcomings of mix networks also apply to Freenet- / > GNUnet-style anonymization schemes? > I suspect that no matter what (existing) adversary > model you pick, plugging a good mix network into your design on the > transport layer gives you the highest anonymity possible. I don't know how GNUnet's architecture compares to mix networks. I *do* know that GNUnet attempts to protect against traffic analysis. If you think mix networks are better, they better have good protection against traffic analysis. Can you point us to any good URLs or papers on how mix networks protect against traffic analysis? Chris _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: SSL fro hidden services
by loki tiwaz 06 Jul '18

06 Jul '18

hi, >>>>That said, the certificate naming scheme may be way off, since there's >>>>no concept of a valid certificate (I doubt verisign will want to sign >>>>one for 786237261871621.onion :) i am considering running an onion-based CA which could be used... i simply need to make a script which allows a user to sign a certificate signing request and produce a signed server key. the server key only needs to have its onion address as content, nothing more is required, and a link to import the CA key into the browser so that it can be trusted automatically by the browser. >>>>However, assuming the user installs your self-signed cert, it *should* >>>>work the same unless there's something I'm missing.) >>>> >>>>Of course, you're really just protecting content from being sniffed >>>>between the user and the entry node (usually, the same machine, but not >>>>always), and the exit node and the hidden service (presumably, you >>>>control both). >>>> >>>>This is my understanding of it -- if someone has a better one please >>>>step on me without hesitation :) yes, this is the case, and it is a valid reason to use ssl. in my opinion, since tor already uses multi-layered encryption anyway, one more layer at the core is not going to create that much of an extra load on the server, and it means that there is no way the traffic can be sniffed at any point - for example a trojan could sniff localhost traffic. also, using onion routing defeats the one way in which SSL can be attacked, by man-in-the-middle intermediaries on the network pathway, which of course cannot be known within the tor network. Also, it should be noted that tor exit nodes could potentially be modified to become men-in-the-middle, although this would not be possible without compromising the key of the server being contacted - another aspect of the advantage of using tor. onion addresses are impossible to remember though - which brings me to another idea - of a name resolution system within the tor network so simpler names can be used. this would require a second directory system, i don't know if it is practical or not, but i thought i should put the idea out there because i2p has name resolution systems, and benig able to type in oniondomainname.onion rather than u15syoa125au.onion would be nice. it would increase the rate of take-up of hidden services, both use and hosting. onion domains could be propagated throughout the onion network, so that every tor node can translate a name into an onion hashed address. there would also need to be a system to prevent name spoofing... how to ensure there is no collisions of names would be tricky - very likely it would require a set of authoritative name servers similar to how there is authoritative onion directory servers. ah dammit, i am always ideas ideas ideas and so little action... prioritising goals is something i find difficult... i think i should make this idea a priority, however, which means joining the dev effort and, at the very least, defining a protocol, if not implementing code... well, anyway, i have put the idea out now. i think that the idea is a good one. tor is coming of age now and ideally tor should aim to provide all of the features one would expect in an internet layer, but with the guiding principle of protecting anonymity always ascendant. an onion-based CA would work much better if the name-resolution system were in place, so i think it should be the priority. loki _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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

[Politech] New law targets online activities designed "to annoy" others [fs]
by Declan McCullagh 06 Jul '18

06 Jul '18

The prohibition: "Whoever...utilizes any device or software that can be used to originate telecommunications or other types of communications that are transmitted, in whole or in part, by the Internet... without disclosing his identity and with intent to annoy, abuse, threaten, or harass any person...who receives the communications...shall be fined under title 18 or imprisoned not more than two years, or both." FAQ: http://news.com.com/2100-1028_3-6025396.html --- http://news.com.com/2010-1028_3-6022491.html Perspective: Create an e-annoyance, go to jail By Declan McCullagh January 9, 2006, 4:00 AM PST Annoying someone via the Internet is now a federal crime. It's no joke. Last Thursday, President Bush signed into law a prohibition on posting annoying Web messages or sending annoying e-mail messages without disclosing your true identity. In other words, it's OK to flame someone on a mailing list or in a blog as long as you do it under your real name. Thank Congress for small favors, I guess. This ridiculous prohibition, which would likely imperil much of Usenet, is buried in the so-called Violence Against Women and Department of Justice Reauthorization Act. Criminal penalties include stiff fines and two years in prison. "The use of the word 'annoy' is particularly problematic," says Marv Johnson, legislative counsel for the American Civil Liberties Union. "What's annoying to one person may not be annoying to someone else." [...remainder snipped...] _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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

[DIYbio] Re: Lethal Bird Flu Transmission Among Humans Now Possible Thanks to Biochemists
by EJ 06 Jul '18

06 Jul '18

According to articles in Nature and Science, the thing that tipped the scales in favor of publication was the discovery of natural flu variants that were halfway towards the full complement of mutations necessary for increased transmission. That supported the argument that such research could help predict what variants should be carefully monitored. -- You received this message because you are subscribed to the Google Groups "DIYbio" group. To view this discussion on the web visit https://groups.google.com/d/msg/diybio/-/xIuTf6sHsHUJ. To post to this group, send email to diybio(a)googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/diybio?hl=en. ----- 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: [ZS] Somehow appropriate. And important. And mythic.
by Bryce Lynch 06 Jul '18

06 Jul '18

On Sat, Nov 10, 2012 at 8:59 AM, Bryce Lynch <virtualadept(a)gmail.com> wrote: > On site and active now. Recognition code: Zero State. > Please redistribute widely: Project Byzantium is on site in the Redhook neighborhood of Brooklyn, NY. We're setting up a mesh network to restore connectivity to the community at the request of the community. We need brains and bodies to help us set up nodes. We need laptops with wireless cards, USB keys, blank CDs. -- The Doctor [412/724/301/703] [ZS (MED)] https://drwho.virtadpt.net/ "I am everywhere." -- -- Zero State mailing list: http://groups.google.com/group/DoctrineZero ----- 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

[liberationtech] CryptoParty in Brussels on 23rd March
by KheOps 06 Jul '18

06 Jul '18

Hi everyone, It may already have been announced, but since I'm not sure I prefer making a reminder :) There will be a CryptoParty held in Brussels on the 23rd of March. It will happen in the offices of European Digital Rights (EDRi, http://edri.org) https://cryptoparty.org/wiki/Brussels#Cryptoparty_Brussels_2 Feel free to forward this to any potentially interested people, even more if you think they lack knowledge to protect their privacy! :) There should be fairly enough tech people, so we need non-tech dudes who are interested in learning! With Cryptolove, KheOps -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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

[liberationtech] Magistrate Judge pwns FBI hacking request
by Gregory Foster 06 Jul '18

06 Jul '18

The WSJ's Jennifer Valentino-DeVries broke this story yesterday, unfortunately behind the WSJ's paywall: https://twitter.com/jenvalentino/status/327172745332916225 For a solid summary, see @rj_gallagher's coverage at Slate: Slate (Apr 25) - "Judge Rejects FBI Attempt to Use Spyware to Infiltrate Unknown Suspect's Computer" by Ryan Gallagher: http://www.slate.com/blogs/future_tense/2013/04/25/texas_judge_denies_fbi_r… Or go straight to the Memorandum and Order, which is quite the read: http://www.scribd.com/doc/137842124/Texas-Order-Denying-Warrant Magistrate Judge Stephen Smith of the Southern District of Texas was presented with an FBI affidavit requesting a Rule 41 search and seizure warrant targeting an unknown computer at an unknown location used by an unknown suspect(s). The lack of specificity was sufficient grounds for declining to issue the warrant, and Judge Smith goes through each of Rule 41's five territorial limits which the government's application failed to satisfy. Although it's interesting to see that the FBI hoped to satisfy the territorial limit by performing the search on the computer's data once it was brought into the Judge's territory, the interesting part concerns just how the FBI hoped to acquire and transport that data: by cracking or phishing into the unknown target computer, installing a sophisticated piece of malware, searching for and gathering information for 30 days, while exfiltrating significant quantities of data out of the system. What kind of data? Although the original affidavit and the revised affidavit were sealed (the FBI having been given at least one opportunity to clarify their intent), Magistrate Judge Smith was kind enough to cite the section of the affidavit which details exactly what information the FBI intended to acquire from the unknown computer: > (1) records existing on the Target Computer at the time the software is > installed, including: > > records of Internet Protocol addresses used; > > records of Internet activity, including firewall logs, caches, browser > history and cookies, "bookmarked" or "favorite" Web pages, search terms > that the user entered into any Internet search engine, and records of > user-typed Web addresses; > > records evidencing the use of the Internet Protocol addresses to > communicate with the [victimbs bankbs] e-mail servers; > > evidence of who used, owned, or controlled the TARGET COMPUTER at the > time the things described in this warrant were created, edited, or > deleted, such as logs registry entries, configuration file, saved user > names and passwords, documents, browsing history, user profiles, e-mail > contents, e-mail contacts, "chat," messaging logs, photographs, and > correspondence; > > evidence of software that would allow others to control the TARGET > COMPUTER; > > evidence of times the TARGET COMPUTER was used; and > > records of applications run. > > (2) prospective data obtained during a 30-day monitoring period, > including: > > accounting entries reflecting the identification of new fraud victims; > > photographs (with no audio) taken using the TARGET COMPUTER's built-in > camera after the installation of the NEW SOFTWARE, sufficient to > identify the location of the TARGET COMPUTER and identify persons using > the TARGET COMPUTER; > > information about the TARGET COMPUTER's physical location, including > latitude and longitude calculations the NEW SOFTWARE causes the TARGET > COMPUTER to make; > > records of applications run. Later in the Memorandum, Judge Smith takes the FBI to task for having the gall to state: > Steps will be taken to assure that data gathered through the technique > will be minimized to effectuate only the purposes for which the warrant > is issued. The software is not designed to search for, capture, relay, > or distribute personal information or a broad scope of data. The > software is designed to capture limited amounts of data, the minimal > necessary information to identify the location of the TARGET COMPUTER > and the user of TARGET COMPUTER. I applaud Magistrate Judge Stephen Smith for his principled action in this circumstance, which is one amongst many significant actions he has taken to resist court secrecy, the abuse of secret "gag" orders, and the application of the Constitution to electronic surveillance requests: http://www.fclr.org/fclr/articles/html/2009/jmffedctslrev5.pdf https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2071399 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2143339 Please consider sharing this information with others. gf -- Gregory Foster || gfoster(a)entersection.org @gregoryfoster <> http://entersection.com/ -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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

DIMACS Workshop on Electronic Voting -- Theory and Practice
by Linda Casals 06 Jul '18

06 Jul '18

************************************************* DIMACS Workshop on Electronic Voting -- Theory and Practice May 26 - 27, 2004 DIMACS Center, Rutgers University, Piscataway, NJ Organizers: Markus Jakobsson, RSA Laboratories, mjakobsson(a)rsasecurity.com Ari Juels, RSA Laboratories, ajuels(a)rsasecurity.com Presented under the auspices of the Special Focus on Communication Security and Information Privacy and the Special Focus on Computation and the Socio-Economic Sciences.. ************************************************ To many technologists, electronic voting represents a seemingly simple exercise in system design. In reality, the many requirements it imposes with regard to correctness, anonymity, and availability pose an unusually thorny collection of problems, and the security risks associated with electronic voting, especially remotely over the Internet, are numerous and complex, posing major technological challenges for computer scientists. (For a few examples, see references below.) The problems range from the threat of denial-of-service-attacks to the need for careful selection of techniques to enforce private and correct tallying of ballots. Other possible requirements for electronic voting schemes are resistance to vote buying, defenses against malfunctioning software, viruses, and related problems, audit ability, and the development of user-friendly and universally accessible interfaces. The goal of the workshop is to bring together and foster an interplay of ideas among researchers and practitioners in different areas of relevance to voting. For example, the workshop will investigate prevention of penetration attacks that involve the use of a delivery mechanism to transport a malicious payload to the target host. This could be in the form of a ``Trojan horse'' or remote control program. It will also investigate vulnerabilities of the communication path between the voting client (the devices where a voter votes) and the server (where votes are tallied). Especially in the case of remote voting, the path must be ``trusted'' and a challenge is to maintain an authenticated communications linkage. Although not specifically a security issue, reliability issues are closely related and will also be considered. The workshop will consider issues dealing with random hardware and software failures (as opposed to deliberate, intelligent attack). A key difference between voting and electronic commerce is that in the former, one wants to irreversibly sever the link between the ballot and the voter. The workshop will discuss audit trails as a way of ensuring this. The workshop will also investigate methods for minimizing coercion and fraud, e.g., schemes to allow a voter to vote more than once and only having the last vote count. This workshop is part of the Special Focus on Communication Security and Information Privacy and will be coordinated with the Special Focus on Computation and the Socio-Economic Sciences. This workshop follows a successful first WOTE event, organized by David Chaum and Ron Rivest in 2001 at Marconi Conference Center in Tomales Bay, California (http://www.vote.caltech.edu/wote01/) Since that time, a flurry of voting bills has been enacted at the federal and state levels, including most notably the Help America Vote Act (HAVA). Standards development has represented another avenue of reform (e.g., the IEEE Voting Equipment Standards Project 1583), while a grassroots movement (http://www.verifiedvoting.org) has arisen to promote the importance of audit trails as enhancements to trustworthiness. ************************************************************** Program: This is a preliminary program. Wednesday, May 26, 2004 7:45 - 8:20 Breakfast and Registration 8:20 - 8:30 Welcome and Opening Remarks Fred Roberts, DIMACS Director 8:30 - 9:15 Ron Rivest (tentative) 9:15 - 10:15 Rebecca Mercuri 10:15 - 10:45 Break 10:45 - 11:30 David Chaum 11:30 - 12:15 Michael Shamos 12:15 - 1:30 Lunch 1:30 - 1:50 European online voting experiences Andreu Riera i Jorba 1:50 - 2:10 Providing Trusted Paths Using Untrusted Components Andre Dos Santos 2:10 - 2:30 Internet voting based on PKI: the TruE-vote system Emilia Rosti 2:30 - 2:50 Andy Neff 2:50 - 3:10 Aggelos Kiayas 3:10 - 3:30 How hard is it to manipulate voting? Edith Elkind and Helger Lipmaa 3:30 - 3:50 Towards a dependability case for the Chaum e - voting scheme Peter Ryan 3:50 - 4:20 Break 4:20 - 4:40 Secure practical voting systems: A Cautionary Note Quisquater 4:40 - 5:25 Rob Ritchie 5:25 - 6:10 Panel (moderator: David Chaum) 6:10 - 7:30 Buffet Dinner - Reception - DIMACS Lounge Thursday, May 27, 2004 7:45 - 8:30 Breakfast and Registration 8:30 - 9:15 Rice University "hack - a - vote" project Dan Wallach 9:15 - 9:50 David Jefferson 9:50 - 10:10 Jeroen Van de Graaf 10:10 - 10:30 Voting, Driving, Death, and Social Security: The risk of centralized voter registration Data Guy Duncan 10:30 - 11:00 Break 11:00 - 11:20 Pedro Rezende 11:20 - 12:05 On optical scanning Doug Jones 12:05 - 1:30 Lunch 1:30 - 2:15 SERVE project Barbara Simons 2:15 - 3:00 Moti Yung 3:00 - 3:20 Ed Gerck 3:20 - 3:50 Break 3:50 - 4:10 Tatsuaki Okamoto 4:10 - 4:30 Lessions from Internet voting during 2002 FIFA WorldCup Korea/Japan(TM) Kwangjo Kim 4:30 - 4:50 Kazue Sako 4:50 - 5:50 Panel (moderator: Sanford Morganstein) ******************************************************************** Registration: (Pre-registration deadline: May 20, 2004) Please see website for complete registration details. ********************************************************************* Information on participation, registration, accomodations, and travel can be found at: http://dimacs.rutgers.edu/Workshops/Voting/ **PLEASE BE SURE TO PRE-REGISTER EARLY** ******************************************************************** --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com --- 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

Re: panix.com hijacked
by Henry Yen 06 Jul '18

06 Jul '18

On Sat, Jan 15, 2005 at 10:50:49AM -0500, Perry E. Metzger wrote: > Panix is highly screwed by this -- their users are all off the air, > and they can't really wait for an appeals process to complete in order > to get everything back together again. from panix shell hosts motd: . panix.net usable as panix.com (marcotte) Sat Jan 15 10:44:57 2005 . . Until we resolve the issue of the domain "panix.com", we have set up . the domain "panix.net" to include the same names and addresses as . "panix.com". . . You may use this as a temporary solution for access to mail, webpages, . etc. Wherever you would use "panix.com", you can replace it with . "panix.net". -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York --- 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