- cypherpunks - lists.cpunks.org

gratitude on being alive and aware - [PEACE] yo!
by Zenaan Harkness 23 Nov '18

23 Nov '18

Awareness of self awareness, and the wonderousness of it all abounds for some. Many have sung gratitude for the reality of being and the abundance of existence itself, which is hereby echoed. Thank you one and all. Gratitude. Our passions, our Soul cries, our eternal search for fulfillment, meaning, love and connection. May your life be abundant and rich in experiences and may you find that which your Soul seeks for you. Peace y'all :) Be Thankful. At Least You’re Alive. Andrew Anglin Daily Stormer November 22, 2018 https://dailystormer.name/be-thankful-at-least-youre-alive/ It’s Thanksgiving. As always, I’m thankful for the honor of running this website, and thankful for all of the people who read it. I’m most thankful when I hear stories of how I’ve helped people. With women, with health, with motivation, with confidence, with whatever. I’m here to help. It’s more than I ever could have asked for, and I will be forever humbled by it. Beyond that, I am as always thankful for my family. This year, I’m especially thankful for Tucker Carlson. …

1 0

Retpolines unnecessary
by Ryan Carboni 22 Nov '18

22 Nov '18

It is likely triggering one branch misprediction will avoid future branch predictions and instead cause a stall. Even if it isn’t, taking the opposite branch once before taking the desired one would leave many alterations to the local cache, unless in a thread on the same core is making some effort to measure which branch was used first. Simply flushing and using an lfence should prevent many issues and just cause a stall. It is funny on stackexchange that L1 and L2 caches (SRAM less vulnerable to radiation) is often disabled due to radiation, according to various askers. It is still bizarre that “AEX” masks registers before context switching out. It seems as if Intel is aware of an issue that they would be liable for. Side channel attacks obtaining information measured in the bits per millisecond or less is unimportant. There are still several “reserved” bits in CPUID, and buffer overreads or underreads, or non-linear overreads would negate many defenses. Possible that C++ could use a time consuming extension preventing parsers reading more than a kilobyte of data, although this would require extensive reprogramming to include it. Although a code review of parsers wouldn’t be bad either. “Mitigate spectre” Well, that solves one bug we’re aware of. What’s the zero day market for browsers again? Oh, right, RCE. RCE is a bit worse than... Spectre. The 1-day market could be impaired by delaying the inclusion of diffs of crash-causing or security bugs in the public code by waiting a day after releasing the binaries. (Although this might encourage monopolies so it should be socially fair to allow access to major downstream distributions) The GPL doesn’t say how timely everyone has to be, and I imagine doing things faster than it would take to make a request for the source code and responding would be legally sufficient. Anyway, the Grsec theory that because someone used an outdated version that it has to be restricted to paying customers is bonkers. I think you can legally call the Grsecurity Firm bonkers.

1 0

A third of "dark-web" taken down by hack...
by John Newman 22 Nov '18

22 Nov '18

https://nakedsecurity.sophos.com/2018/11/21/hacker-erases-6500-sites-from-t… I don't know if the numbers are accurate, but it shows remarkable centralization of hidden services, which seems to (obviously) be a bad idea....

3 3

Analysis of ProtonMail Cryptographic Architecture
by grarpamp 21 Nov '18

21 Nov '18

Cryptology ePrint Archive: Report 2018/1121 An Analysis of the ProtonMail Cryptographic Architecture Nadim Kobeissi Abstract: ProtonMail is an online email service that claims to offer end-to-end encryption such that "even [ProtonMail] cannot read and decrypt [user] emails." The service, based in Switzerland, offers email access via webmail and smartphone applications to over five million users as of November 2018. In this work, we provide the first independent analysis of ProtonMail's cryptographic architecture. We find that for the majority of ProtonMail users, no end-to-end encryption guarantees have ever been provided by the ProtonMail service and that the "Zero-Knowledge Password Proofs" are negated by the service itself. We also find and document weaknesses in ProtonMail's "Encrypt-to-Outside" feature. We justify our findings against well-defined security goals and conclude with recommendations. Category / Keywords: applications / public-key cryptography, pgp Date: received 18 Nov 2018, last revised 19 Nov 2018 Contact author: nadim at symbolic software Available format(s): PDF | BibTeX Citation Version: 20181120:032816 (All versions of this report) Short URL: ia.cr/2018/1121 https://eprint.iacr.org/2018/1121.pdf

1 0

Fwd: [Cryptography] Buffer Overflows & Spectre
by grarpamp 21 Nov '18

21 Nov '18

---------- Forwarded message ---------- From: Henry Baker <hbaker1(a)pipeline.com> Date: Tue, 20 Nov 2018 18:42:46 -0800 Subject: Re: [Cryptography] Buffer Overflows & Spectre To: Jon Callas <jon(a)callas.org> Cc: cryptography(a)metzdowd.com In-line comments below. At 05:17 PM 11/20/2018, Jon Callas wrote: >I understand what you're saying, but here, irony perhaps, but not betrayal, no. > >I've been dealing with this for a year now, and it's not quite what your saying, if I understand you. It's nothing to do with buffer overflows, but with memory disclosures. It's a sidechannel or covert channel issue. > >Your metaphor about automobiles doesn't quite hit the mark. In the case of the emissions testing that was an intentional thing put in to fool regulations. CPU manufacture is not regulated at all, and Spectre is so unlike emissions or even braking that it's hard to comment about what would tune the metaphor. It's not fraud, by any sense, since there's no intent there. Moreover, there are no direct analogues of such a problem to automotive technologies. (Note that I didn't call it a bug; it's not a bug, it is an emergent consequence of design.) [I'm a bit of a car buff, so I'm quite well versed in the facts of auto safety and emissions history.] Of course, Spectre was intentional. The whole point of speculation is to "fool" the standard benchmarks, and run those fast even if the results on non-benchmark code are insecure or buggy. Your arguments work equally well for the auto companies -- they have "merely" tuned their engines to fool the standard emissions benchmarks, even if the results the rest of the time are complete crap. Your comment "CPU manufacture is not regulated at all" is precisely what Ralph Nader found when he published his book "Unsafe at any Speed" in 1965 that led to significant government regulation of auto safety. Since the CPU manufacturers have clearly put profits ahead of people, it is now time to regulate them -- either through legislation or through common-law lawsuits. [Come to think of it, Nader needs to write "Unsafe at any Speed: 2.0" to describe the current CPU Spectre crisis!] >Out of order instruction execution first appeared in the IBM 360/91 back in 1968. In our world, it appeared in PCs with the PPC 603, and in x86 CPUs with the AMD K5 and the Pentium Pro. Back in the day, there were some Multics papers about covert channels (Paul Karger did some nice ones) related to speculative execution, but by and large no one really considered it an issue. It's been a mainstay of CPU design for well over twenty years. Automobiles in the 1960's had been deathtraps and smog generators for 50 years before Nader was finally able to stop the "car"-nage. A slow-motion train wreck is still a train wreck, and those companies responsible are just as guilty as those causing fast-motion train wrecks. >If one wants to rail about something, it would be the misplaced use of metrics and the truism that "if you can't measure it, it doesn't exist." We're in this mess because we care about performance (which we can measure) more than anything like security (which we can't). I think it's far more like the present mess with C compilers where the compiler people have gone and created so much undefined behavior that C is no longer a low-level language. There was a time where the problem with C was that since there was little to no optimization in the compiler that it all fell to the author to write efficient code (which was often silly because the other major facet of C was its alleged portability). As C delivered on the portability promises and started getting into more optimization, that led us to the security problems of today where it is very hard to write a program with no undefined behavior. We're up to nearly 200 different types of undefined behavior. You'll have to speak for yourself. Many of us in the computer science community have long been advising correctness and security over speed. The C-oriented computer architectures of the 1980's and 1990's merely "externalized" the costs of software safety and security and "socialized" those costs for society as whole to bear, while "privatizing" the profits from these unsafe systems. We're still paying billions of dollars a year tracking down the bugs and buffer overflows in software written by C-weenies in the 1980's. [Check out the tests used by Microsoft and other SW companies in the 1980's to weed out careful programmers; "Move Fast and Break Things" is an attitude that started long before Facebook.] >Anyway, getting back to this, the problem we face is how to make systems that are faster without these side effects. The promises that CPU designers have been giving us and also we demand is what gets hand waved as "Moore's Law" a shorthand for seeing continuous, regular performance gains over time. If you go back to the Congressional hearings about auto safety and auto emissions, you will find exactly the same set of excuses. The auto industry was building cars that could go well over 100 mph, but whose tires blew up over 90mph, and whose brakes and suspensions were completely inadequate for the power and speeds of these vehicles. Regarding auto emissions, check out the story of how Honda embarrassed the Detroit auto industry by demonstrating Honda's better technology to Congress on one of GM's *own engines*. >On top of this, there's no easy way to fix pipelining to make this go away. Even getting rid of speculative execution doesn't make it go away, since it is timings that cause the memory leak. Even getting rid of caches doesn't fix the problem because RAM often has its own internal caches (which cause timing differences) and even bare RAM has timing differences caused by locality of reference. Getting rid of high-resolution clocks doesn't fix it, either, because a spin loop is a close enough approximation to a clock to make it work. > >The only real ways to get rid of this is to go back to an architecture where the CPU clock is the same as the memory clock, there are no speedups in memory fetching nor in pipelines, and likely more. I'll bet even that doesn't do it. I really don't care any more about excuses. I see 4/8/12 core processors whose entire computational load is handling 50-100 (or more) Javascript components so that tens of advertisers can better track me as I read a single paragraph of text. Every additional computational cycle is more than eaten up with larger Javascript programs, so web pages are slower than they were twenty years ago. I really don't care to give up my security to enable more of this garbage. >There are people thinking about things that could fix this, some of which are outrÃ©, and some are complete rethinks of computer architecture, like flat address spaces with memory tagging. > >This is far, far worse than most people think because it goes to the very core of the fact that any sort of a distinguisher is a side channel. > > Jon _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Hard to tell the truth when the sayer isn’t protected
by Ryan Carboni 21 Nov '18

21 Nov '18

https://media.kaspersky.com/pdf/Guerrero-Saade-VB2015.pdf Naturally those sorts of things anger people, cause them to organize. You never know what might happen in response. I’m not sure if a mailing list can cite an academic article.

1 0

ZeroWedgie: Teaching the world a lesson, global capitalist ruling class -style‼ - [PEACE]
by Zenaan Harkness 20 Nov '18

20 Nov '18

How to teach the world a bloody lesson, authored by your friendly "capitalist" ruling class oligarchs. The 'Hitlergate' Hearings & Rescuing America >From "The Brink Of Fascism" https://www.zerohedge.com/news/2018-11-19/hitlergate-hearings-rescuing-amer… … In other words, the global capitalist ruling classes are about to teach the world a lesson. It is the same basic lesson they have been teaching the world since the dissolution of the Soviet Union. They taught it in the former Yugoslavia. They taught it in Greece, and Iraq, and Libya. They have taught it throughout the Middle East. They are about to teach it throughout the West. The lesson is, resistance to global capitalism is not just futile, it is suicidal. The lesson is, play with identity politics and all that “cultural wars” stuff to your heart’s content, but fuck with global capitalism and we will squash you like a tomato bug. …

1 0

Why is AEX implemented in SGX if Intel implemented x86 securely?
by Ryan Carboni 20 Nov '18

20 Nov '18

The buried lede in NEMESIS and FORESHADOW: For the “case of a fault or external interrupt, the processor executes an Asynchronous Enclave Exit (AEX) procedure that saves the execution context securely in a preallocated state save area inside the enclave, and replaces the CPU registers with a synthetic state to avoid di- rect information leakage to the untrusted ISR.” Seems. Odd. I dunno. Did anyone read x86 documentation?

1 1

For the relevant foreign powers
by Ryan Carboni 19 Nov '18

19 Nov '18

The US government controls nearly all aspects of my life, and assigns people to meet with me every day.

2 1

Cryptocurrency: Yawn
by grarpamp 19 Nov '18

19 Nov '18

https://i.redd.it/05vwyvyj8az11.png

1 0