- cypherpunks - lists.cpunks.org

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

public Freenet webGUI
by damiengray＠tutanota.com 18 Nov '18

18 Nov '18

Ever wonder what's on Freenet? If you're curious, there's a public FProxy webGUI at http://gel2bzjxrvcmqpji.onion:8888 <http://gel2bzjxrvcmqpji.onion:8888/>. It's part of a darknet on the Tor OnionCat IPv6 overlay network. The other 20 peers are listed here: http://zerobinqmdqd236y.onion/?ceffbd4a36f954e0#UTW52y4tvML8B0Wwu9i3Wl2BhbG… <http://zerobinqmdqd236y.onion/?ceffbd4a36f954e0#UTW52y4tvML8B0Wwu9i3Wl2BhbG…>. It runs in a Debain 8.11 Docker container, which is hosted in a Debain 9.6.0 KVM domain, and that in turn is hosted on a Ubuntu 18.10 KVM VPS. Iptables rules at VPS and KVM domain levels block all Internet access except through Tor and OnionCat.I'll check it periodically. If someone has broken it, I'll restart the Docker container. If someone has managed to break the KVM domain, I'll restore that from backup. And if someone has gone the extra mile to break the VPS, I'll restore that from backup. This may seem bizarre to privacy lovers. I mean, I could be logging everything! But the point is providing easy-to-use access to Freenet that's secured from third parties. If you decide that it's worth the hassle, I recommend running your own node, connecting through OnionCat IPv6 peers. Or through I2P GarlicCat peers, if you like. While I could be logging everything, that's arguably more-or-less irrelevant, because Tor renders you and the node mutually anonymous. Not perfectly anonymous, true. But there's arguably little risk, unless you and/or the node have been targeted. Just be prudent. Especially be prudent about downloading files from the node. I recommend using Whonix, on a machine with full-disk encryption. Or Tails, with encrypted USB storage.

2 1

X86 dispatch contention vulnerability
by Ryan Carboni 17 Nov '18

17 Nov '18

While many x86 implementation vulnerabilities in the past involve either electromagnetic emissions or cache timing attacks, I have not read anything about instruction dispatch contention. According to anger fog’s research, Intel’s implementation of the x86 instruction set does not dispatch more than three of a single instruction, and it has been so for a long time. Irregardless of their design decisions for instruction dispatch, this provides a side channel in which two cooperating processes operating on the same core can conduct half-duplex communication at the rate of 2 bits per cycle by one process attempting to compete with another process for the same capacity for dispatches over a single instruction (0, 1, 2, 3). While I do not have the resources to know how x86 processors handles dispatch contention issues, if it is handled in a regular and non-random manner, it would reach that theoretical level of severity. This violates certain access controls assumed to be imposed by the kernel. I suppose I can’t collect my quarter million dollar prize if I publish this to the world?

4 11

Redefining the Kilogram
by jim bell 17 Nov '18

17 Nov '18

https://www.engadget.com/2018/11/16/kilogram-officially-redefined/ Today, scientists voted to change the definition of the kilogram as well as three other units of measurement -- the ampere, the kelvin and the mole. The vote took place at the General Conference on Weights and Measures in Versailles, France and the new definitions will be based on "what we call the fundamental constants of nature," as Estefanía de Mirandés of the International Bureau of Weights and Measures (BIPM) told Science News, instead of the less precise definitions these measurements are currently tied to. The kilogram, for example, is defined by a physical cylinder known as Le Grand K that's stored in a vault outside of Paris. These redefinitions have been in the works for some time. "This is the most important decision that the BIPM has made in maybe 100 years, which may be a slight exaggeration, but at least since 1960 when they adopted the International System of Units," Terry Quinn, emeritus director of the BIPM, told Engadget last year. And while the changes won't necessarily be reflected in your day to day life, they'll help scientists make more accurate measurements going forward. [end of quote] Jim Bell

1 0