October 2019 - cypherpunks - lists.cpunks.org

you can safely bet the 1933 USD fix did not apply to Rothschild - Executive Order 6102 "no personal gold ownership" - [PEACE]
by Zenaan Harkness 14 Nov '19

14 Nov '19

A little history for the uninitiated: https://www.zerohedge.com/news/2018-09-29/how-executive-order-6102-doomed-a… Here's the thing, the uber-elite, such as Rockefellers, Rothschilds etc, have been hoarding (using that term loosely - the Fed's reserves are in serious question, as was the tonnes under the WTC towers, each of which apparently "disappeared", more facts required) gold using fiats. The fiat system has been designed to cyclically collapse (you thought the Federal Reserve was constitutional/lawful?), and those fiats are used for more generalised systematized hoarding, such that when the collapse happens, and the mathematical reset trigger is pulled, those holding the gold are the same old Goldbergs, Silversteins, Rothschilds and the rest. So a reset is not useful in and of itself. What is required is a systemic change. There are simple solutions, but they do require a general consciousness - the unwashed sheeple need to become a little more washed/ aware. Good luck,

1 1

[WAR] the Pentagon's "White Helmets" "moderate head choppers" descend to depths unheard of
by Zenaan Harkness 12 Nov '19

12 Nov '19

Horrific. Trigger warning. * DISTURBING IMAGES: White Helmets BUSTED killing babies in PR stunt to start war in Syria http://theduran.com/warning-disturbing-images-white-helmets-busted-killing-… White Helmets have been caught faking rescues and doctoring dead children. ** Qatar-owned Al Jazeera reports Assad is bombing Idlib with White Phosphorus http://theduran.com/qatar-owned-fake-news/ ------------------------------------------------------------ Al-Jazeera headquarters Doha, Qatar. More fake news: Al Jazeera, reported that Syrian jets have bombed the town of Idlib using White Phosphorus. ** Michael Savage: complete “false flag in Syria.” No sarin gas, most likely phosgene gas http://theduran.com/michael-savage-complete-false-flag-in-syria-no-sarin-ga… ------------------------------------------------------------ Michael Savage: complete “false flag in Syria.” No sarin gas, most likely phosgene gas Savage: “How is is this an ‘America first’ decision?” ** The human cost of Donald Trump’s war crime (VIDEO) http://theduran.com/the-human-cost-of-donald-trumps-war-crime/ ------------------------------------------------------------ widow The widow of a slain Syrian soldier speaks about her loss. ** Hezbollah condemns the ISIS massacre of Egyptian Christians http://theduran.com/hezbollah-condemns-the-isis-massacre-of-egyptian-christ… ------------------------------------------------------------ Hezbollah urged Muslims to unite in order to protect Christians from violence. ** John McCain blasts the Trump administration–the honeymoon is over http://theduran.com/john-mccain-blasts-the-trump-administration-the-honeymo… ------------------------------------------------------------ U.S. Senator McCain arrives on a visit at a migrant center near the village of Adasevci John McCain wants more war...lots more. ** Fake news story in mainstream AND alt-media slanders Russia and Iran http://theduran.com/exclusive-fake-news-story-in-mainstream-and-alt-media-s… ------------------------------------------------------------ The story says that Russia and Iran threatened to attack US forces if a 'red line' was crossed. This is an outright lie. ** Iranian President Rouhani telephones Vladimir Putin–united front on Syria is strengthened http://theduran.com/iranian-president-rouhani-telephones-vladimir-putin-uni… ------------------------------------------------------------ Both leaders pledged their commitment to aid Syria in the fight against terrorism and to work together to stabilise the volatile region.

4 8

The Jewish/Israeli Question - USS Liberty - "anti semitic facts" - [PEACE] [MINISTRY]
by Zenaan Harkness 08 Nov '19

08 Nov '19

>From the "Those whom you may not criticize coming under more and more criticism and scrutiny and doing everything in their power to censor the world as a result" department... Create your world, 'I Will Never Leave a Fallen Comrade' Except if He Was on the USS Liberty https://russia-insider.com/en/i-will-never-leave-fallen-comrade-except-if-h… Ray McGovern … On the 47th anniversary of that unprovoked attack let’s be clear about what happened: Israeli messages intercepted on June 8, 1967, leave no doubt that sinking the USS Liberty was the mission assigned to the attacking Israeli warplanes and torpedo boats as the Six-Day War raged in the Middle East. Let me repeat: there is no doubt – none – that the mission of the Israeli Defense Forces (IDF) was to destroy the USS Liberty and kill its entire crew. … How I Came to See That Many 'Anti-Semitic Canards' Are Actually True https://russia-insider.com/en/how-i-came-see-many-anti-semitic-canards-are-… "Asbestos Ron" Unz … "The notorious Jewish tendency to shamelessly lie or wildly exaggerate has sometimes had horrifying human consequences." "If the most extreme “anti-Semitic canards” were probably true, then surely the whole notion of anti-Semitism warrants a careful re-examination." … A Few Simple Arguments Which Cast Serious Doubt on the 'Holocaust' https://russia-insider.com/en/few-simple-arguments-which-cast-serious-doubt… MICHAEL WALSH Sit the students down and explain slowly: “According to the World Jewish Encyclopaedia there resided 2.4 million Jews in German-Occupied Europe. After the war, 3.8 million Jewish ‘holocaust survivors’ were receiving pensions from the German government. Tragically, the remaining six million were lost.” … Okay, let’s start again: “Doctor Charles P. Larson, one of America’s leading forensic pathologists, in 1945 was assigned to the US Army’s Judge Advocate General’s department. As part of a US war crimes, investigation team Dr. Larson performed autopsies at Dachau and some twenty other camps examining more than 100 corpses on some days. Dr. Larson confirmed that none of the autopsies he performed showed any evidence of death by poison gas. But, his conclusion was that death had occurred by typhus and starvation (as a consequence of USAAF and RAF saturation bombing).” … The Fags, Jews, and God-Haters in League With Jordan Peterson https://russia-insider.com/en/fags-jews-and-god-haters-league-jordan-peters… Brother Nathanael IF THE NEW YORK TIMES is promoting it as an alliance of intellectuals foiling the mainstream conversation then you know the conversation is Jew approved. The “alliance”—known as the Intellectual Dark Web—is Jew heavy, peppered with sodomites, with not one member openly anti-Jewish or anti-Israel. Others are white atheist liberals with a couple of Middle Easterners thrown in for diversity’s sake, one of whom is a Lebanese Jew. …

1 2

Hornberger: "repeal of all drug laws is a necessary pre-requisite for a free society"
by Zenaan Harkness 08 Nov '19

08 Nov '19

Posted with vehement in principle support for the position, and the need, to repeal all drug "prohibition" laws, to return some sanity to the Western world, eliminate the bulk of all alleged "criminals" in the West, and massively reduce crime and Western incarceration rates. The numbers are in, the empirical evidence from Amsterdam to South America are overwhelmingly compelling, and the logic never left those with second neurone in the first place - even for those who are not 'statutorily illegal' drug users. Hornberger: The Evil Of The Drug War https://www.zerohedge.com/health/hornberger-evil-drug-war https://www.fff.org/2019/10/28/the-evil-of-the-drug-war/ With the exception of the U.S. national-security state and its foreign policy of empire and intervention and its torture, state-sponsored assassinations, coups, alliances with dictatorial regimes, invasions, occupations, wars of aggression, illegal and unconstitutional wars, mass secret surveillance, indefinite detention, secret prison camps, drug experimentation on unsuspecting people, denial of due process, denial of trial by jury, kangaroo military tribunals, and other dark-side practices, it would be difficult to find a better example of an evil and immoral program than the war on drugs. Consider: 1. Everyone, including the most ardent drug-war proponent, agrees that this decades-long program has failed to achieve its goal, which is a drug-free society. 2. If failure was the only consequence of this program, that would be one thing. But it’s not. Drug laws have brought Into existence drug gangs, drug cartels, gang wars, drug assassinations, drug kidnappings, burglaries, robberies, murders, muggings, and official corruption. 3. The drug war is also the most racially bigoted government program since segregation, perhaps even more so. Under segregation, government officials used the force of law to keep the races separated, but at least they permitted blacks to keep living in the community. With drug laws, they have been able to remove blacks entirely from communities and relocate them into places called penitentiaries, where they are forced to spend a large portion of their lives. They have also been able to use drug laws to harass, abuse, insult, and humiliate African-Americans, Latinos, and other racial minorities. That’s not to say, of course, that all law-enforcement agents and all judges are racially bigoted. It is simply to say that for those who are racially bigoted, the drug war is like heaven on earth, in that it enables them to exercise their bigotry in a legal manner and even get praised for it. 4. The drug war has played a major role in the destruction of liberty in America. Just think: They actually put people into jail for doing nothing more than ingesting a substance that politicians and bureaucrats, both at the state and federal level, don’t approve of. Who cares whether politicians and bureaucrats approve of a particular substance? What business is that of theirs? Actually, it’s none of their business what a person puts into his mouth. Freedom necessarily entails the right to ingest whatever a person wants to Ingest, no matter how harmful or destructive it might be. When people live in a society where government officials can punish them for ingesting unapproved substances, there is no way that people in that society can legitimately be considered free. The repeal of drug laws — all drug laws, not just marijuana laws — is a necessary pre-requisite for a free society. It’s also a prerequisite for a just and humane society, one that treats drug addiction and drug use as a private problem, not a criminal-justice one.

3 4

Stay Awesome China - Wu and Za... Maker and Docu.. WestPlatformAttacked
by grarpamp 08 Nov '19

08 Nov '19

5 6

Re: [From xorcist offlist] Cloudflare & NoDAPL again w/ a ROTF
by Razer 05 Nov '19

05 Nov '19

Fwiw, for those who aren't aware... The point of trolls like this one, 'xorcist', and cyberpiggie et all is to stalk individuals posts on lists with garbage so people start to think, whenever the one being targeted posts, "Oh fuck that means I'm gonna see all that shit from xxx(a)xxx.xxx again and wish the targeted person would stop posting and just lurk. Stupid... Simple... Social engineering. Rr

8 56

Sim Theory
by grarpamp 05 Nov '19

05 Nov '19

So many people have proposed we're simulated... https://en.wikipedia.org/wiki/Simulation_hypothesis Now why would such an extremely advanced civilization / collective want to simulate us? Is this an unanswered question? Certainly they have long since - solved biology, live forever, down/up load their brains against trauma - solved life and mobility throughout their universe - lost and forgotten their prehistory - etc They could sim anything they want. So why sim us? Because something happened to them, something very big, something serious and existentially threatening. And now they're *desperately* trying to learn about death, life, humanity, the individual... something they lost but is still encoded in them just enough to let them think of making the sim...

9 20

Quantum Computers
by jim bell 05 Nov '19

05 Nov '19

https://www.bloomberg.com/view/articles/2016-09-06/quantum-computers-are-co… [partial quote] Quantum mechanics, Carl Sagan once observed, is so strange that "common sense is almost useless in approaching it." Scientists still don't understand exactly why matter behaves as it does at the quantum level. Yet they're getting better at exploiting its peculiar dynamics -- in ways that may soon upend the technology business. One of the most interesting applications is in computing. In theory, quantum computers could take advantage of odd subatomic interactions to solve certain problems far faster than a conventional machine could. Although a full-scale quantum computer is still years off, scientists have lately made a lot of progress on thematerials, designs and methods needed to make one. And that could have some striking benefits. Quantum computers could simulate how atoms and molecules behave, to the greatadvantage of chemists and drug designers. They could solveoptimization problems -- say, how to efficiently route airplane traffic -- far faster than current technology can. They could speed advances in artificial intelligence, improve sensors, and lead to the design of stronger and lighter industrial materials.[end of partial quote] Jim Bell

8 12

Why Google's Quantum Victory Is a Huge Deal—and a Letdown
by jim bell 04 Nov '19

04 Nov '19

https://www.wired.com/story/why-googles-quantum-computing-victory-is-a-huge…

4 3

How a months-old AMD microcode bug destroyed my weekend [UPDATED]
by coderman 03 Nov '19

03 Nov '19

[Stylized image of spiders creeping across screen covered with code.][Enlarge](https://cdn.arstechnica.net/wp-content/uploads/2019/10/bugs… / Ryzen 3000's RDRAND function—what should be a high-quality pseudo-random number generator—just returns 0xFFFFFFFFF every time, until its microcode is patched. This weekend, I was excited to deploy my first Ryzen 3000-powered workstation in my home office. Unfortunately, a microcode bug—originally discovered in July but still floating around in large numbers in the wild—wrecked my good time. I eventually got my Ryzen 3700X system working, and it's definitely fast. But unfortunately, it's still bugged, and there's no easy way to fix it. Not long after the product launch, AMD Ryzen 3000 customers started noticing problems with their shiny new CPUs. Windows users couldn't successfully launch Destiny 2 (due to a power-management bug, unrelated to the one sidelining my system), and Linux users in many cases couldn't even get their system to boot. Jason Evangelho [covered](https://www.forbes.com/sites/jasonevangelho/2019/07/12/amd-motherb… the initial discovery and report of the bug at Forbes back in July, and an AMD representative provided him with a statement by email: > AMD has identified the root cause and implemented a BIOS fix for an issue impacting the ability to run certain Linux distributions and Destiny 2 on Ryzen 3000 processors. We have distributed an updated BIOS to our motherboard partners, and we expect consumers to have access to the new BIOS over the coming days. This sounds happy and upbeat, but the reality isn't quite so simple. When there's a bug in the CPU microcode, you're at the mercy of your motherboard vendor to release a new system BIOS that will update it for you—you can't just go to some download link at AMD and apply a fix yourself. AMD responded to the bug in July. As far as I can tell, AMD did so only by direct email response; there's no press release about it—and the company's response made it sound like everything would be fixed in a week or two. I have the unfortunate duty of reporting to you, three months later, that it is not. What’s an RDRAND? The microcode bug in question is a faulty response to the RDRAND instruction. Modern x86_64 CPUs—beginning with Intel's Broadwell and AMD's Zen architectures—are supposed to have high-quality onboard random number generators (RNGs), which use thermal "noise" to very rapidly offer high-entropy pseudorandom numbers to anybody with kernel-level access who wants it. [RDRAND](https://en.wikipedia.org/wiki/RdRand) is, in turn, the instruction that provides these random numbers. All of this is supposed to be fairly failsafe. There's a CPUID function call that checks for the availability of RDRAND, and there's also a "carry bit" in the return value from a call to RDRAND that's supposed to let the calling application know if the CPU's RNG was unable to generate a sufficiently random number. Unfortunately, unpatched Ryzen 3000 says "yes" to the CPUID 01H call, sets the carry bit indicating it has successfully created the most artisanal, organic high-quality random number possible... and gives you a 0xFFFFFFFF for the "random" number, every single time. Obvious RDRAND bug impacts When the RDRAND bug in Ryzen 3000 first surfaced back in June, Linux users widely reported that their entire Ryzen 3000-powered systems wouldn't boot. The failure to boot was due to systemd's use of RDRAND—and it wasn't systemd's first clash with AMD and a buggy random-number generator, unfortunately. A much earlier bug in older CPUs caused some AMD systems to stop generating properly "random" numbers after resuming from suspend. The new bug caused Ryzen 3000 users to never get any proper random numbers at all. Both problems caused lockups in Linux operating systems using systemd, so in May systemd committed a [patch](https://github.com/systemd/systemd/commit/b62bc66018fa1ada09554e7ee4… that falls back to using alternate RNG sources if systemd receives the characteristic 0xFFFFFFFF back from the RNG. (This kinda sucks, because 0xFFFFFFFF is technically a perfectly valid random number—the implication here is that, after a sufficient length of time, systemd will decide any system has a buggy RNG when it eventually receives the "bad" number, even if it has never seen that number before.) Systemd's patch is ugly, but it certainly works well enough to allow systems to boot. Unfortunately, it doesn't fix the actual problem, which is that the CPU's random number generator is no more "random" than a two-headed penny. On my own system, I spent my entire weekend chasing phantom problems, first suspecting the system's brand-new RX 590 graphics card and (necessarily) updating distro and kernel versions before haring off from there. [My shiny new system kept barfing these nasty BUG: soft lockup<br /> —PU#n stuck for 22s errors, which would rapidly lock the whole system up. This call trace from /var/log/syslog didn't tell me the actual problem, but it was the first clue.](https://cdn.arstechnica.net/wp-content/uploads/2019/10/calltrace.png… / My shiny new system kept barfing these nasty BUG: soft lockup —PU#n stuck for 22s errors, which would rapidly lock the whole system up. This call trace from /var/log/syslog didn't tell me the actual problem, but it was the first clue. Jim Salter Eventually, after many false trails and much swearing, coffee, and less-respectable beverages, I actually read the call trace from my frequent CPU lockups—and "WireGuard" was right there, in every one of them. As it turns out, WireGuard relies on RDRAND (when available) to generate new session IDs. The session IDs need to be unique, and WireGuard wants them not to be simple consecutive integers, so it pulls a pseudorandom value from RDRAND, compares it against its existing session ID list to make sure there's no collision, then assigns it to the session. Read that last part again carefully—it makes sure there's no collision first. If an existing session has the same ID as the new number, WireGuard asks RDRAND for another "random" number, checks it for uniqueness, and so on. Since RDRAND on my system—and any non-microcode-updated Ryzen 3000 system—always returned 0xFFFFFFFF no matter what, that means infinite loop. Infinite loops in kernel code are bad; they introduce you to the value of the hardware reset button in a hurry. I want to be very clear here, this is not a WireGuard bug! WireGuard correctly checks to see if RDRAND is available, fetches a value if it is, and correctly checks to see if the carry bit is set. Then it indicates that, not only is there a value, it's a properly random one. Nevertheless, it's a problem that will lock up affected systems hard. A modern system needs high-quality pseudo-random numbers for lots of tasks, and the security implications of "random" meaning "always return0xFFFFFFFF" are difficult to predict. One obvious candidate is Address Space Layout Randomization (ASLR). Both [Windows](http://blog.ptsecurity.com/2012/12/windows-8-aslr-internals.html) and [Linux](https://lwn.net/Articles/569635/) use RDRAND as at least part of the randomness used to make sure code is never loaded in the same order twice, which mitigates against [stack-smashing](https://en.wikipedia.org/wiki/Stack_buffer_overflow) attacks. Fixing the problem—or at least recognizing it As AMD's representatives told reporters back in July, the real fix comes from applying BIOS updates to your motherboard and hoping that the BIOS update also includes the microcode patch for the CPU itself. When I checked my own BIOS using the dmidecode utility, I saw a date of August 12, 2019. But when I looked at Asus' download page for my motherboard, I saw downloads dated in September! Hurray! So I downloaded the BIOS update, saved it to a FAT32 thumb drive, rebooted my system, and went into setup. Unfortunately, after successfully applying the update and rebooting again, I realized my error—yes, Asus showed a later date for the BIOS, but the actual version was the same as the one I already had—3.2.0. My CPU still thought 0xFFFFFFFF was the randomest number ever, always, no matter what. At this point, I began to get paranoid—systemd had already quietly worked around the bug. But with most applications just quietly ignoring the problem, how would I know if it ever had been patched? What if two years later, I was still vulnerable to stack-smashing that I shouldn't have been, due to ASLR that wasn't actually randomizing? I discovered that I could use the linux utility hexdump against the kernel device /dev/hwrng to demonstrate that I had the problem. Unfortunately, the WireGuard project's Jason Donenfeld warned me that /dev/hwrng could, on some systems, derive its randomness from other sources—so while seeing a bunch of FF from it demonstrates that you have the problem, seeing valid pseudorandom data doesn't necessarily demonstrate that you don't. So he generously whipped up a couple of test utilities for the purpose that safely access RDRAND directly. If you're a Linux user, you can download [rdrand-test.zip](https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdr…, unzip it, and run it directly in the folder that you unzipped it in. ./amd-rdrandbug will tell you in plain English whether you have this specific bug, and ./test-rdrand will output 20 test RDRAND fetches. So you can confirm for yourself that you're not vulnerable to similar bugs either—if running ./test-rdrand produces the same set of values every time, it doesn't really matter whether they "look random," your RNG is broken! If you're a Windows user, you have a little more work ahead of you. First, [download](https://ubuntu.com/download/desktop) an Ubuntu desktop installer, then create an Ubuntu installer thumb drive. Then you can boot into the Ubuntu thumb drive's live environment (click "Try Ubuntu") and download and run the tests from there: you@ubuntu-live:~$ wget https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-test.zip you@ubuntu-live:~$ unzip rdrand-test.zip you@ubuntu-live:~$ cd rdrand-test you@ubuntu-live:~$ ./amd-rdrand.bug [In a sufficiently broad dataset, 20 consecutive 0xFFFFFFFF returns might be considered a valid "random" grouping. This is not a sufficiently broad dataset.](https://cdn.arstechnica.net/wp-content/uploads/2019/10/rdrand-fai… / In a sufficiently broad dataset, 20 consecutive 0xFFFFFFFF returns might be considered a valid "random" grouping. This is not a sufficiently broad dataset. Jim Salter Conclusions A broken random-number generator is a very serious bug, and it's troubling that more hasn't been said or done about this issue by AMD in the last three months. Ryzen 3000 is a great CPU platform in general, and I've been very impressed with the new system... except for spending an entire frustrated weekend troubleshooting it, being uneasy about the impact this will have on my overall system security, and having no idea when I can expect to be able to actually fix it. I reached out to AMD representatives earlier today, and they've responded with questions about my hardware but no solutions yet. I'll update this article with any fixes or recommendations as they arrive. Update: When I reached out to AMD for comment, a representative inquired about the make and model of my motherboard (Asrock Rack X470D4U) and the representative reached out in turn to Asrock. Asrock's team offered a custom BIOS available with the appropriate microcode fix; I respectfully declined to flash a one-off BIOS for me and me only, but the better news is that Asrock told AMD that the BIOS update should be publicly available in mid-November. (It is worth noting that some motherboards do already have BIOS updates available which do include the microcode fixes. Why the Asrock Rack X470D4U wasn't one of them is anybody's guess.) Readers in comments have suggested workarounds and mitigations in the meantime. The first was to pass nordrand as an argument to GRUB when booting. That doesn't fix the issue; it tells the kernel not to use the RDRAND instruction, but that doesn't have any impact on the advertised availability of the instruction in general. It's still exposed to the system, and any code that checks for the availability of RDRAND via CPUID is still going to see it there, and will still be able to use it directly. This is also the case with the similar random.trust_cpu Linux boot option. Neither of these workarounds actually disables RDRAND, so neither actually fixes the issue. Readers also suggested that if the amd64-microcode package were installed, it would fix the issue. This, too, is not the case; the amd64-microcode and intel-microcode packages are both installed by default on all Ubuntu 19.10 systems, including the one I'm experiencing the RDRAND failure on. I contacted AMD and asked representatives to check the status of that package and see if anything needs to (or can) be done about updating it. https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-…

5 6