- cypherpunks - lists.cpunks.org

Cryptocurrency: SEC Seeks Your Input On ETF's
by grarpamp 21 May '19

21 May '19

https://www.sec.gov/rules/sro/cboebzx/2019/34-85896.pdf Variety of ETF's, Trusts, Futures in the pipeline. US SEC and other agencies seek and accept input from users. Responses are also published. III. Procedure: Request for Written Comments The Commission requests that interested persons provide written submissions of their views, data, and arguments with respect to the issues identified above, as well as any other Use the Commission's Internet comment form http://www.sec.gov/rules/sro.shtml Send an e-mail to rule-comments(a)sec.gov. Please include File Number SR-CboeBZX- 2019-004 on the subject line. Send paper comments in triplicate to Secretary, Securities and Exchange Commission, 100 F Street, NE, Washington, DC 20549-1090. Comments on the proposed rule change can be found at: https://www.sec.gov/comments/sr-cboebzx-2019-004/srcboebzx2019004.htm Interested persons are invited to submit written data, views, and arguments regarding whether the proposal should be approved or disapproved [by 20 days from today]. SECURITIES AND EXCHANGE COMMISSION (Release No. 34-85896; File No. SR-CboeBZX-2019-004) May 20, 2019 Self-Regulatory Organizations; Cboe BZX Exchange, Inc.; Order Instituting Proceedings to Determine Whether to Approve or Disapprove a Proposed Rule Change to List and Trade Shares of the VanEck SolidX Bitcoin Trust On January 30, 2019, Cboe BZX Exchange, Inc. ("BZX" or "Exchange") filed with the Securities and Exchange Commission ("Commission"), pursuant to Section 19(b)(1) of the Securities Exchange Act of 1934 ("Act")1 and Rule 19b-4 thereunder,2 a proposed rule change to list and trade shares of SolidX Bitcoin Shares ("Shares") issued by the VanEck SolidX Bitcoin Trust ("Trust") under BZX Rule 14.11(e)(4), Commodity-Based Trust Shares. The proposed rule change was published for comment in the Federal Register on February 20, 2019.3

1 0

Goro Shimura, 89, Mathematician RIP
by John Young 21 May '19

21 May '19

Goro Shimura, 89, Mathematician With Broad Impact, Is Dead https://www.nytimes.com/2019/05/13/obituaries/goro-shimura-dead.html "His insights led to tools widely used in modern cryptography." "A proof of a form of the Taniyama-Shimura conjecture would also prove Fermat's Last Theorem. In the 1990s, Andrew Wiles, then also at Princeton, figured out how to do just that, and Fermat's Last Theorem had finally been proved true. Dr. Wiles, now at the University of Oxford in England, wrote in an email that the Taniyama-Shimura conjecture was "a fundamental pivot in the proof of Fermat's Last Theorem." The proof also employed other key results of Dr. Shimura's research, he said."

2 1

Hidden service persistent connections (Traffic Analysis)
by grarpamp 21 May '19

21 May '19

On 5/17/19, Memory Vandal <memvandal(a)gmail.com> wrote: > Are client connections to a hidden service .onion address that do not > disconnect for hours safe? > > It may be a big file download or multiple keep-alive transactions that uses > the established connection over and over for lets say few hours. > > If its not safe then what should be the max time a connection to .onion > service should get disconnected so that it uses a new circuit when it > reconnects? GPA and big global and regional network operators can pull out traffic patterns. NSA's own slide decks and papers, as well as academic researchers whitepapers in tor bib and elsewhere have confirmed this. Here are some degenerate traffic pattern... while : ; do wget onion ; sleep 5 ; done ping6 -w 5 <onioncat_peer> Who thinks those is or is not observable? Now receive or send your real N-GiB file, plot the packet timings and bandwidth variations going aross your nic. Do not forget the circuit creation wavefront either. Who thinks those are or are not observable at the other end (and even throughout in some cases)? Now add in targeted DoS blinking out nodes. And add in Sybil. Who disbelieves those tools effective? Who disbelieves "Op Ivy Bells" "641a" "Bumblehive" and "parallel construction"? Tor and many other overlay networks fail to deploy traffic fill and regulation, or try traffic mix and other various means to lessen or defeat such analysis. There are a few papers and overlays and hardware hopefully trying such and other things for the near future. You can list all the ones you can find here if you want, and see about creating, running and supporting them too. Maybe if you adopt true distributed privacy cryptocurrency instead of central fiat shitcoins you can start put them spyings and so many other bad things against humanity into "max defund time" too. Wake up.

3 2

yet another false flag attack courtesy of the anglo american fascists.
by Punk 20 May '19

20 May '19

https://consortiumnews.com/2019/05/17/confirmed-chemical-weapons-assessment…

2 1

Re: [Cryptography] What are the privacy implications of bitpay
by grarpamp 20 May '19

20 May '19

On 5/19/19, jamesd(a)echeque.com <jamesd(a)echeque.com> wrote: > With the designed method of bitcoin, you can pay someone quite > anonymously. They issue payment address, which is actually a public > key, and then value mysteriously appears in the blockchain for that > public key, with no indication of how it got into the blockchain. > > Bitpay, however, initiates a direct conversation between the payee and > the wallet, and it looks to me that entities cosy with the state are > pushing bitpay onto us, demanding payment by bitpay. > > Bitpay initiates a conversation between the website and the wallet, and > thus, and thus, modulo vpns and all that, locates the physical location > of the wallet. But that in itself is pretty harmless, because you have > to interact with their website anyway, so you already leak that information. > > What additional information goes into a bitpay payment? Seems to me > that it is being pushed for ulterior and unrevealed reasons. The underlying problem is that most coins are not privacy coins at the protocol level, and hardly that with most mix, but moreso with better coinjoin etc. Or you can push out from privacy coins per tx / day / week, with lots of cost and headaches, or just adopt and use them natively... Zcash, Monero, many more before long, as the better overall solution. The point of opensource cryptocurrency is to evolve and survival of fittest past the genesis... nonprivacy coins are early legacy tech and hardly fit and cannot survive privacy and other attacks... you know much more now, so go and evolve past those early designs. No, you're talking to the chain, bitpay reads the chain. Of course bitpay is a third party seeing both sides, so they're still vomit compared to direct onchain to payee wallet. And governments love that middle siphon op. Expect them to require a checkout ID swipe for that soon... so you have about 30 minutes to adopt and entrench faster than they can fuck you over with that too... thanks to you wasting your time with blocksize and price, instead of adoption and advancing designs. If using the complete garbage Gemini backed Flexa SPEDN app then yes, that's even more severe exploitation of privacy and so many other things on a whole other level beyond even Bitpay. So now brick and mortar retail is trending poorly in regard true adoption of true distributed cryptocurrency. Coins without privacy are worse than fiat cash, no one wants worse, it leads straight to your life controlled and enslaved hell. You need to educate payees on wallet ops, conversions, holdback profits as investment, promise of true distributed cryptocurrency. And everyone on privacy coins. It's not that hard. "Money" is ultimately backed by nothing but belief. And now there's a much more agnostic, fair and less murderous choice than Fiat. So don't let the BankGovCorp FUD propaganda brigade and puppet masters sway you. Distributed scalable private cryptocurrency is solveable tech, and you know it's power for you. So go solve and adopt it.

1 0

Hacking History
by coderman 19 May '19

19 May '19

https://www.muckrock.com/project/hacking-history-419/ Hacking History A look at government investigations of hackers and their works. The government has hundreds of thousands of pages of documents on hackers, hacking groups and high profile hacks, some of that the government investigated and some that the government infiltrated. From the FBI, to the Secret Service and the many government agencies that’ve been hacked. These files are important pieces of history for the evolution of the cyber domain, government investigations, and hacktivism. All costs go towards the release of the files, which will be made publicly available. Backed by Kelly Shortridge, Thomas Dullien, Brian Mcinnis, Joe Hamelin, and 14 others. $2,083.37 raised out of $9,500.01. 4 days, 5 hours remaining So far, just under three million pages of FBI records identified, funds have been raised for 25,000. [Legion of Doom](https://www.muckrock.com/foi/united-states-of-america-10/legion-of-do… – 46,250 pages ($1,598.50 – funded separately!) [LulzSec](https://www.muckrock.com/foi/united-states-of-america-10/lulzsec-3… – 7,500 pages ($220 – funded!) [OurMine](https://www.muckrock.com/foi/united-states-of-america-10/ourmine-6… – 25,173 pages ($760) [GoatSec](https://www.muckrock.com/foi/united-states-of-america-10/goatsec-6… – 15,374 pages ($460) [David Kernell](https://www.muckrock.com/foi/united-states-of-america-10/david-ker… – 2,871,253 pages ($15 for every 500 pages) [WANK worm](https://www.muckrock.com/foi/united-states-of-america-10/wank-worm-in… – 3 pages ($0 – [released](https://www.muckrock.com/news/archives/2019/may/14/nasa-wank-worm…!) [FBI International Cyber Sweep for DDoS Attackers](https://www.muckrock.com/foi/united-states-of-america-10/ddos-sw… – 32,000 pages ($955) Lots more to come, including the FBI file on the [Cult of the Dead Cow](https://www.muckrock.com/foi/united-states-of-america-10/cult-of-the-d…. You can see the full list of the requests [here](https://www.muckrock.com/foi/list/?page=1&per_page=100&projects=419). Read more about the project [here](https://www.vice.com/en_us/article/vb9bjj/hacking-history-foia-projec….

1 0

[OT] [MS-DOS] [Music] System Bits (2019) - Full Album
by Cecilia Tanaka 19 May '19

19 May '19

It's a rainy Sunday here and a dear friend of mine provided some musical fun for us... ;) https://youtu.be/tUy1MEpqbvk Warm hugs and tender kisses! Take care everyone, please! <3 Ceci ---------- Loving. Caring. Sharing. Being Excellent To Each Other And To Our Hackerspace. <3 ---------- "Don't let anyone rob you of your imagination, your creativity, or your curiosity. It's your place in the world; it's your life. Go on and do all you can with it, and make it the life you want to live." - Mae Jemison

1 0

>20, 000 Linksys routers leak historic record of every device ever connected
by Steven Schear 19 May '19

19 May '19

https://arstechnica.com/information-technology/2019/05/33-linksys-router-mo… Independent researcher Troy Mursch said the leak is the result of a flaw in almost three dozen models of Linksys routers. It took about 25 minutes for the Binary Edge search engine of Internet-connected devices to find 21,401 vulnerable devices on Friday. A scan earlier in the week found 25,617. They were leaking a total of 756,565 unique MAC addresses. Exploiting the flaw requires only a few lines of code that harvest every MAC address, device name, and operating system that has ever connected to each of them. The flaw allows snoops or hackers to assemble disparate pieces of information that most people assume aren’t public. By combining a historical record of devices that have connected to a public IP addresses, marketers, abusive spouses, and investigators can track the movements of people they want to track. The disclosure can also be useful to hackers. The Shadowhammer group, for instance, recently infected as many as 1 million people after hacking the software update mechanism of computer maker ASUS. The hackers then used a list of about 600 MAC addresses of specific targets that, if infected, would receive advanced stages of the malware.

1 0

Re: WIRED: A Cisco Router Bug Has Massive Global Implications
by John Young 19 May '19

19 May '19

What's the security benefit of Red Balloon's attacks? Is this not a type of extortion or maybe angling for bragging rights, a bribe to keep quiet or a buy-out from deep-pocketed targets. Hard to distinguish white hats from black and gray (also Red Hat), sanctimony from villainy. All emulating national security racketeering, or more like religious whipsawing fear and salvation. Leaking secrets has become a masturbation porn racket too, always was, mea culpa. At 12:27 PM 5/14/2019, you wrote: >âââââââ Original Message âââââââ >On Tuesday, May 14, 2019 4:39 AM, jim bell <jdb10987(a)yahoo.com> wrote: > >> >>WIRED: A Cisco Router Bug Has Massive Global Implications. >><https://www.wired.com/story/cisco-router-bug-secure-boot-trust-anchor>https://www.wired.com/story/cisco-router-bug-secure-boot-trust-anchor > >The Cisco 1001-X series router doesn't look much >like the one you ><https://www.wired.com/story/find-a-new-router/>have >in your home. It's bigger and much more >expensive, responsible for reliable connectivity >at stock exchanges, corporate offices, your >local mall, and so on. The devices play a >pivotal role at institutions, in other words, >including some that deal with hypersensitive >information. Now, researchers are disclosing a >remote attack that would potentially allow a >hacker to take over any 1001-X router and >compromise all the data and commands that flow through it. > >And it only gets worse from there. > >To compromise the routers, researchers from the >security firm Red Balloon ><https://thrangrycat.com/>exploited two >vulnerabilities. The first is a bug in Ciscoâs >IOS operating systemnot to be confused with >Apple's iOSwhich would ld allow a hacker to >remotely obtain root access to the devices. This >is a bad vulnerability, but not unusual, >especially for routers. It can also be fixed >relatively easily through a software patch. > >"Itâs not a trust buoy." > >Ang Cui, Red Balloon > >The second vulnerability, though, is much more >sinister. Once the researchers gain root access, >they can bypass the router's most fundamental >security protection. Known as the Trust Anchor, >this Cisco security feature has been implemented >in almost all of the companyâs enterprise >devices since 2013. The fact that the >researchers have demonstrated a way to bypass it >in one device indicates that it may be possible, >with device-specific modifications, to defeat >the Trust Anchor on hundreds of millions of >Cisco units around the world. That includes >everything from enterprise routers to network switches to firewalls. > >In practice, this means an attacker could use >these techniques to fully compromise the >networks these devices are on. Given Cisco's >ubiquity, the potential fallout would be enormous. > >âWeâve shown that we can quietly and >persistently disable the Trust Anchor,â says >Ang Cui, the founder and CEO of Red Balloon, who >has a history of revealing major ><https://www.wired.com/story/electromagnetic-pulse-hack/>Cisco >vulnerabilities. âThat means we can make >arbitrary changes to a Cisco router, and the >Trust Anchor will still report that the device >is trustworthy. Which is scary and bad, because >this is in every important Cisco product. Everything.â > > >Dropping Anchor > > >In recent years, security-minded companies have >increasingly added "secure enclaves" to >motherboards. Different solutions go by >different names: Intel has SGX, Arm has the >TrustZone, Apple has the secure enclave. And Cisco has the Trust Anchor. > >They variously comprise either a secure part of >a computerâs regular memory, or a discrete >chipa saafe, secluded oasis away from the >bedlam of the computerâs main processor. No >user or administrator can modify the secure >enclave, no matter how much control they have >over the system. Because of its immutable >nature, the secure enclave can watch over and >verify the integrity of everything else. > >Secure-computing engineers generally view these >schemes as sound in theory and productive to >deploy. But in practice, it can be dangerous to >rely on a sole element to act as the check on >the whole system. Undermining that >safeguardwhich has proven possible in many >companiesâ implementationsstrips a device of >critical protecttions. Worse still, manipulating >the enclave can make it appear that everything >is fine, even when it's very much not. > >That's the case with the Cisco 1001-X. The Red >Balloon team showed specifically that they could >compromise the device's secure boot process, a >function implemented by the Trust Anchor that >protects the fundamental code coordinating >hardware and software as a device turns on, and >checks that it's genuine and unmodified. It's a >crucial way to ensure that an ><https://www.wired.com/story/fancy-bear-hackers-uefi-rootkit/>attacker >hasnât gained total control of a device. > >On Monday, Cisco is ><https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco…>announcing >a patch for the IOS remote-control vulnerability >the Red Balloon researchers discovered. And the >company says it will also provide fixes for all >product families that are potentially vulnerable >to secure-enclave attacks like the one the >researchers demonstrated. Cisco declined to >characterize the nature or timing of these fixes >ahead of the public disclosure. It also disputed >that the secure boot vulnerability directly >impacts the Trust Anchor. According to its >security bulletin, all fixes are still months >away from release, and there are currently no >workarounds. When the patches do arrive, Cisco >says, they will "require an on-premise >reprogramming," meaning the fixes can't be >pushed remotely, because they are so fundamental. > >âAs a point of clarification, Cisco advertises >several related and complementary platform >security capabilities,â a spokesperson told >WIRED in a written statement. âOne of which >that is relevant to this discussion is Cisco >Secure Boot which provides a root of trust for >system software integrity and authenticity. >Another capability offered within certain Cisco >platforms is the Trust Anchor module, which >helps provide hardware authenticity, platform >identity, and other security services to the >system. The Trust Anchor module is not directly >involved in the work demonstrated by Red Balloon.â > >Cisco seems to make a distinction between its >"Trust Anchor Technologies," "Trustworthy >Systems," and "Trust Anchor module," that may >explain why it only considers secure boot to be implicated in the research. > >The Red Balloon researchers disagree, though. >They note that Ciscoâs ><https://patents.google.com/patent/US20120303941>patent >and other ><https://www.cisco.com/c/en/us/products/collateral/security/cloud-access-sec…>documentation >show that the Trust Anchor implements secure >boot. If secure boot is undermined, the Trust >Anchor is necessarily also defeated, because all >of the tools are in a chain of trust together. >You can see it visualized in ><https://www.cisco.com/c/dam/en_us/about/doing_business/trust-center/docs/tr…>this >Cisco diagram. > > >âThatâs why they call it an anchor! Itâs not a trust buoy,â Cui says. > > >FPGA Tour > > >The researcher group, which also includes Jatin >Kataria, Red Balloonâs principal scientist, >and Rick Housley, an independent security >researcher, were able to bypass Ciscoâs secure >boot protections by manipulating a hardware >component at the core of the Trust Anchor called >a >â<https://www.wired.com/2016/05/googles-making-chips-now-time-intel-freak/>field >programmable gate array.â Computer engineers >often refer to FPGAs as âmagic,â because >they can act like microcontrollersthe >processors often used in embedded devvices but >can also be reprogrammed in the field. Thatt >means unlike traditional processors, which can't >be physically altered by a manufacturer once >they're out in the world, an FPGA's circuits can be changed after deployment. > >FPGAs pull their programming from a file called >the bitstream, which is usually custom-written >by hardware makers like Cisco. To keep FPGAs >from being reprogrammed by mischievous >passersby, FPGA bitstreams are extremely >difficult to interpret from the outside. They >contain a series of complex configuration >commands that physically dictate whether logic >gates in a circuit will be open or closed, and >security researchers evaluating FPGAs have found >that the computational power required to map an >FPGAâs bitstream logic is prohibitively high. > >"This is proof that you canât just rely on the FPGA to do magic for you." > >Josh Thomas, Atredis > >But the Red Balloon researchers found that the >way the FPGA was implemented for Ciscoâs Trust >Anchor, they didnât need to map the whole >bitstream. They discovered that when Ciscoâs >secure boot detected a breach of trust in a >system, it would wait 100 secondsa pause >programmed by Cisco engineers, perhaps to buy >enough time to deploy a repair update in case of >a malfunctionand then physically kill the power >on the device. Thhe researchers realized that by >modifying the part of the bitstream that >controlled this kill switch, they could override >it. The device would then boot normally, even >though secure boot accurately detected a breach. > >âThat was the big insight,â Red Balloonâs >Kataria says. âThe Trust Anchor has to tell >the world that something bad has happened >through a physical pin of some sort. So we >started reverse engineering where each pin >appeared in the physical layout of the board. We >would disable all the pins in one area and try >to boot up the router; if it was still working, >we knew that all of those pins were not the one. >Eventually we found the reset pin and worked >backward to just that part of the bitstream.â > >The researchers did this trial-and-error work on >the motherboards of six 1001-X series routers. >They cost up to about $10,000 each, making the >investigation almost prohibitively expensive to >carry out. They also broke two of their routers >during the process of physically manipulating >and soldering on the boards to look for the reset pin. > >An attacker would do all of this work in advance >as Red Balloon did, developing the remote >exploit sequence on test devices before >deploying it. To launch the attack, hackers >would first use a remote root-access >vulnerability to get their foothold, then deploy >the second stage to defeat secure boot and >potentially bore deeper into the Trust Anchor. >At that point, victims would have no reason to >suspect anything was wrong, because their devices would be booting normally. > > >âThe exposure from this research will >hopefully remind the companies out there beyond >just Cisco that these design principles will no >longer stand as secure,â says Josh Thomas, >cofounder and chief operating officer of the >embedded device and industrial control security >company Atredis. âThis is proof that you >canât just rely on the FPGA to do magic for >you. And itâs at such a low level that itâs >extremely difficult to detect. At the point >where youâve overridden secure boot, all of >that trust in the device is gone at that point.â > > >Even Bigger Problems > > >Thomas and the Red Balloon researchers say they >are eager to see what types of fixes Cisco will >release. They worry that it may not be possible >to fully mitigate the vulnerability without >physical changes to the architecture of >Ciscoâs hardware anchor. That could involve >implementing an FPGA in future generations of >products that has an encrypted bitstream. Those >are financially and computationally more >daunting to deploy, but would not be vulnerable to this attack. > > > ><https://www.wired.com/author/lily-hay-newman/?itm_campaign=AuthorCarveLeft>Lily >Hay Newman covers information security, digital privacy, and hacking for WIRED. > > >And the implications of this research don't end >with Cisco. Thomas, along with his Atredis >cofounder Nathan Keltner, emphasize that the >bigger impact will likely be the novel concepts >it introduces that could spawn new methods of >manipulating FPGA bitstreams in countless >products worldwide, including devices in high-stakes or sensitive environments. > >For now, though, Red Balloonâs Cui is just >worried about all of the Cisco devices in the >world that are vulnerable to this type of >attack. Cisco told WIRED that it does not >currently have plans to release an audit tool >for customers to assess whether their devices >have already been hit, and the company says it >has no evidence that the technique is being used in the wild. > >But as Cui points out, âTens of thousands of >dollars and three years of doing this on the >side was a lot for us. But a motivated >organization with lots of money that could focus >on this full-time would develop it much faster. >And it would be worth it to them. Very, very worth it.â

4 5

EMP missile
by jim bell 18 May '19

18 May '19

Air Force has deployed missiles that could fry electronics of Iran https://mol.im/a/7037549 via http://dailym.ai/android

4 3