Complexity theory isn't required to be a programmer - <AUTHOR> http://mortoray.com/2015/03/24/complexity-theory-isnt-required-to-be-a-programmer/ <comment><USER2> This is to me a deeply weird article.

Thematically, it makes a case for complexity not being important to software development. I disagree, but stipulating that the author is correct, where does that slippery slope end? Virtually no formalized CS knowledge is required to make expert use of Microsoft Excel, which is itself an extremely important programming environment. What parts of CS does this analysis _include_ in the requirements for development? Is it important to know how a hash function works if your language gives you a dictionary ADT? Is it important to understand the memory hierarchy if you're just shuttling things into and out of an SQL database? There's a rather large population of "Rails programmers" and "PHP programmers" that need know very little more than an "HTML programmer" does to get their job done.

But it's the specifics of the argument that really bug me. The author seems to be making a case that even if you understand complexity, it's hard to deploy it in a real application. That idea seems totally alien to me. I don't routinely analyze the complexity of a sort or a shortest-paths graph reduction, but I certainly feel like I benefit from understanding how the typical algorithms used to solve those problems scale with the size of their inputs. Simpler: any time you select a binary tree instead of a hash table for your lookup table because you realize you need range queries or sorted traversal, aren't you leaning on complexity theory?

<comment><USER3> > Simpler: any time you select a binary tree instead of a hash table for your > lookup table because you realize you need range queries or sorted traversal, > aren't you leaning on complexity theory?

Only a nominal amount. You probably only need to spend a few hours watching YouTube videos to make these sorts of decisions, or pass a phone screen. Whereas there are entire classes and textbooks that cover only complexity theory.

Software is a weird industry because the best and most famous developers tend to be the ones who make software for other developers. And those folks tend to know a ton about software engineering. But the actual folks using those tools don't need to know all that much, and they're generally the ones making all the money.

<comment><USER4> That goes for _anything_. A carpenter needs to know wood theory, but doesn't need to know how to genetic engineer new species of trees.

</comment></comment></comment><comment><USER5> This article betrays the author's misunderstanding of complexity theory. Complexity theory is about finding algorithms which provably optimize some notion of efficiency. Any notion of efficiency. Complexity theory is not equivalent to using asymptotic notation to describe things. In particular, when you find an algorithm that has, say, O(n) worst-case runtime, then you know that the time-complexity of the problem you're trying to solve is O(n). It could be better, like O(log n), and the goal of complexity theory is to do better or prove you can't. You could also try to find the query complexity of a learning problem in terms of the accuracy desired, or the round complexity of a problem solved by MapReduce algorithms in terms of the number of processors and the size of the input.

> How does the algorithm perform in concurrent computing? Clearly we'd prefer > an algorithm that can scale over processors to one that can't ... Certainly > there is a way to put this all together in theory, but I don't know those > details.

There are no details to know. Any time you have any parameter of any system which can grow (processors, input size, time, space, cache layers) you can describe _anything depending on that parameter_ using asymptotic notation to get a rough estimate of its efficiency. This is not a question of complexity, just a question of how to express growth rates succinctly. Knowing how to reason about rough estimates is essential for engineers because they have to have some idea about why the thing they're building will conform to specifications at least in principle before devoting the resources to measuring it precisely.

And to reiterate: none of this has anything to do with complexity theory except that in complexity theory we happen to use asymptotic notation very heavily. The author's problem is with mathematical language being used in the workplace.

<comment><USER2> Yes, that's a compelling point, but to be clear: he's saying that the asymptotic analysis is itself not useful to programmers. We don't even reach the question of whether the _field_ of complexity theory is relevant to programmers.

<comment><USER5> Exactly. He's using the wrong words to describe his point, which is that he doesn't think this particular mathematical language is useful. To someone who is fluent in that language, he makes it clear that he doesn't know how to use the language effectively (to stretch it, at times it doesn't seem like he even understands the semantics). But indeed, how could any sort of language be useful unless you know how to use it effectively?

</comment></comment></comment><comment><USER6> I don't know why we keep passing around this kind of anti-intellectual, faux- controversial drivel. Very little is _required_ to be a programmer (whatever it means to be a programmer). No, you don't need to be an expert on algorithm analysis or complexity theory or some other CS theoretical thing to be a programmer, but it's quite obviously better to be able to reason in a certain way about certain problems (and of course asymptotic analysis isn't everything when dealing with practical applications).

<comment><USER7> > _" I don't know why we keep passing around this kind of anti-intellectual, > faux-controversial drivel."_

There is a rather vocal minority in this community who think that attending universities is a waste of time. These people are naturally interested in notion that things commonly taught in universities, but frequently glossed over when self-teaching or at "hacker schools", are not necessary.

<comment><USER8> > not necessary

No education is necessary, but that doesn't make it devoid of value. Speaking as a US citizen, I truly believe what my country and countless others around the globe desperately need is better and accessible education, absolutely including the Arts.

The opposing viewport can likely be called anti-intellectual in fairness.

<comment><USER7> Perhaps I should have mentioned that I am not a member of this minority.

If I am hiring for a developer position, I consider at least a basic knowledge of complexity to be necessary. There are too many developers who are familiar with it for me to waste my time on ones that are not.

I am not speaking of "necessary" in a universal sense, since that would be nearly impossible to define and a useless concept even if we could. If we really get down to it, _breathing_ isn't _necessary_...

</comment></comment></comment></comment><comment><USER9> It's not required to be a programmer, much like learning how to drive manual is not required to be a driver.

However, if you want someone to pay you the high salary to be a race car driver, then you better know how to drive manual.

There are plenty of positions where people can program and do programming tasks without a great deal of depth of knowledge in terms of programming. And they can make a living doing this.

<comment><USER10> Bad analogy, Formula 1 drivers use selectable-gear, automatic transmissions. It's more efficient to have a computer run the clutch.

<comment><USER11> F1 cars use sequential gearboxes, which aren't the same as automatic (actually, they're different from typical manual transmissions as well).

They _do_ have driver-operated clutches, though... actually there's TWO of them, usually the bottom two paddles on the left and right of the wheel. They're only necessary when starting the car from stationary, after that the computer takes over. It's actually notoriously difficult to operate them, if you take a look at this video of Richard Hammond driving an F1 car, he takes several tries to get it moving.

[http://www.youtube.com/watch?v=9773pisjCSw](http://www.youtube.com/watch?v=9773pisjCSw)

Not to mention, there are other types of highly-paid race car drivers.

</comment></comment></comment><comment><USER12> Indeed, you don't!

And we all look forward to your app being featured on [http://accidentallyquadratic.tumblr.com](http://accidentallyquadratic.tumblr.com) :)

</comment><comment><USER13> "Consider what O(n) means: nothing. That's right, if somebody tells me something is O(n) it truthfully tells me nothing on its own."

You, my good sir, are totally mistaken. O(n) is a set of functions that grow at most linearly with n, ignoring constants. O(n) is a rich mathematical notation that tells a _lot_ of things on its own. If someone tells you that something 'is' O(n) what they actually mean is that they have a function that is _an element_ of O(n). Again, a very concise and powerful statement on its own. Of course you can't say "this tree is O(n)" because a tree is not a function. That'd be like saying "this apple is dumb". Don't blame the notation, blame the user.

</comment><comment><USER14> It is sad but true. Complexity theory isn't required to be a programmer, it isn't required to release products and that's one of the reasons why a lot of software product we directly/indirectly use everyday sucks so much.

<comment> vezzy-fnord I think the main reason for Wirth's law stinging as much as it does, isn't so much because of ignorance of algorithmic complexity. Rather, it's because most programmers (and all the languages, libraries, frameworks and various assorted tools and materials that they use) still operate on a mental model of how computer architecture works that is literally decades out of date.

Mainstream infrastructure hasn't done a stellar job in seamlessly abstracting new hardware features (though compiler construction is still decent there in many regards). The one that has, isn't usually mainstream.

</comment></comment><comment><USER15> Complexity theory isn't required when prototyping an application. It is required when engineering an application.

<comment><USER16> Not necessarily. In fact it can get in the way because complexity theory ignores all those ugly little constant numbers. More important than complexity theory is actually doing your own measuring and benchmarking, something I've seen forgotten during engineering attempts far more often.

<comment><USER17> "In fact it can get in the way because complexity theory ignores all those ugly little constant numbers."

No, it doesn't. A given person may be, but the theory does not. It so happens that complexity theory makes heavy use of a mathematical construct, the "big-O notation", that makes it easy to ignore low-order term's impact on a process, but that is a tool it uses, not the totality of the theory.

I assure you that if you walk up to a complexity theorists and say "Your ignoring of constant factors makes your entire discipline worthless!" you're more likely to get laughed at than blow their minds.

You want to analyze the real impact of some algorithm in the face of having Big Ints and dealing with cache issues? Complexity theory is ready for you. I've seen it done. The equations get nastybig fast, but fortunately computer algebra systems can chew right them. Amusingly, in the end you end up doing something very similar to O() anyhow and just start semi-arbitrarily chopping off insignificant terms to figure out what's actually going on in the enormous expression. But this can still be a useful exercise to get a sense of where the low-order terms may be dominating, for how long, and whether there's anything useful to do about it.

</comment></comment></comment><comment><USER10> I think programmers _should_ need to know complexity theory, because if there is a "programmer" type job that can be done without knowing it, then we should be working hard to eliminate that job through automation. In other words, dissolve the class of programmers that supposedly don't need to know complexity theory.

Also, big-O is not the be-all, end-all of complexity theory. What a ludicrous sentiment.

<comment><USER5> Unfortunately, nobody has yet figured out how to automate the process of encoding arbitrary sets of business rules written by non-programmers into code.

<comment><USER10> The problem isn't that the tools don't exist. The problem is that the work is organized to make someone not-the-manager think about the details. It's not just "arbitrary" business rules that need to be encoded, it's "poorly defined, poorly thought-out" business rules.

That's why SQL didn't take off as a lay-person interface to databases; even though it was meant to be a system anyone could use, you can't get around the fact that you still need to know what you want and what comprises what you want. Your typical middle-manager type knows neither.

That's also why UML can't be converted to a program: if it did, it would call managers out on their inconsistent logic and the manager would just give up and make someone else do it. The fact that it doesn't compile is _a feature_ , one that enables UML to make managers feel like they are being a part of the technical process.

It's not a technical problem, it's a cultural one.

</comment></comment></comment><comment><USER18> One thing the author doesn't mention is np-completeness. You need complexity theory to introduce/explain the concept of np-complete problems and I would argue that knowledge of those are necessary for a good programmer. Otherwise you might waste a lot of time trying to find a polytime algorithm for something which (arguably) doesn't have one.

</comment><comment><USER19> > If we're dealing with collections people tend to mean time complexity, > because most collections have a space complexity of O(n). I say most, since > a common one, the radix tree, does not.

Does it not? It can't be less than O(n) simply by the pigeonhole principle and it doesn't look like it's more than that.

<comment><USER20> I think your confusion comes from the fact that n does not refer to the number of elements, it refers to the sum of the sizes of all of the elements. Let the number of elements be m, for this discussion.

For elements that have a constant/uniform size, this distinction is pointless. However, for things like strings, there can be a large variance in the size.

Applying the pigeonhole principle informs us that the radix tree has a lower bound of O(m); but remember that O(n) could be quite a bit larger than that. A radix tree works by only storing one copy of duplicated prefixes of the elements; it still has an upper-bound space complexity of O(n), but the expected complexity is lower than that.

<comment><USER21> It depends on how your computer works. If pointers are magic O(1) values, then sure. But if you need as many bits in a pointer as necessary to distinguish the total number of pointers, then you don't get an asymptotic size advantage.

Also, using n as the sum of the sizes of all the elements is not normal.

<comment><USER20>
        > If pointers are magic O(1) values

Um... pointers _are_ O(1) size. Usually either a fixed 32 or 64 bits.

        > then you don't get an asymptotic size advantage.

I even said that! I specifically said that it's still O(n) upper bound, but that the expected case is lower than that.

Though to be fair, I should have written Ω(m) instead of O(m) when discussing the lower bound.

        > using n as the sum of the sizes of all the elements is
        > not normal.

1\. I didn't say it was normal; just that in this case, that's what it was referring to.

2\. It is though! Worded another way, n is the size of the data being stored.

<comment><USER21> >Um... pointers are O(1) size. Usually either a fixed 32 or 64 bits.

If you want to talk about asymptotic growth of an algorithm, you need it defined on a machine model that supports infinite memory. Saying that pointers are special O(1) size values are a reasonable way to do that. Another way is to let them be variable size, and include that cost in your measurements. With your 64-bit pointers, you're overpaying that cost. And the transition from 32 bit pointers to 64 bit pointers is an object lesson on the real existence of this logarithmic factor that you'd like to pretend doesn't exist.

Edit: also, going with O(1) pointers, the expected asymptotic space usage doesn't mean anything without specifying the probability distribution of dictionaries involved (maybe parameterized on the size n). It's not hard to construct one that changes the outcome.

<comment><USER20> Ok, fair.

It would have been correct for the original author to have written that most collections have ϴ(n) space complexity, where radix trees only have O(n) space complexity.

It's common for people to use O when they mean ϴ or Ω. All the original statement was saying is that most collections use as much data as you put in, but some (like radix tree) can use less.

(for fun, if we don't give O(1) pointers: If I'm not mistaken, radix tree has O(m*log(m)+n), Ω(m) space-complexity, which is O(n) iff the average size of an element is ≥ log(m); which it almost certainly would be)

<comment><USER19> > which is O(n) iff the average size of an element is ≥ log(m); which it > almost certainly would be

That's stronger than a mere "almost certainly". At least some constant fraction (dependent on the alphabet) would be of size Ω(log m) for some base also dependent on the alphabet, so the average size is also Ω(log m).

I'm not sure how you get your best case, though. It seems to me that the best case has at least Θ(m) nodes since there are m contained strings. The best case for this is each being of minimum size - which is constant size. Each node but the first has a pointer to it of size Ω(log m), so the overall minimum cost is Ω(m log m).

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> If you distinguish a 'software engineer' from a 'programmer' this article makes sense to me. But the article does not even use the word 'reduction' which seemed to be 90% of what we did for homework in my computational complexity class.

</comment><comment><USER23> Yes you could get things done most of the time without knowing it, but why bother? It is not hard to learn and you'll need it anyways someday if you code enough.

</comment><comment><USER5> Considering that people were having typical days of programming before complexity theory existed, of course it's not required. I don't know of anybody who seriously claims that it is required.

<comment><USER24> Complexity theory had been explored, if not deeply, somewhat before what we'd consider "typical days of programming": [https://en.wikipedia.org/wiki/Computational_complexity_theor...](https://en.wikipedia.org/wiki/Computational_complexity_theory#History)

<comment><USER5> I suggest you read that more closely. There was no theory laid out until the late 60's, and "complexity theory" was not a field until the 70's. On the other hand, there is a long list of programming languages invented in the 50's.

</comment></comment></comment><comment><USER25> In english we tend to use complexity to refer more to how intricate a system is rather then algorithmic run time. It's confusing because programming is involved with the intricacy of systems in a big way. That's why imho, the word 'complexity' is actually a really bad naming choice. Typically when I refer to complexity, I refer to it as complexity in Design and structure.

Programming deals more with this type of design complexity for which currently no theory exists. How do quantify whether one program is more intricate then another? How do we quantify whether the functional style is less complex then an object oriented style? There's no way. Since no theory exists, it largely comes down to using intuition and design to deal with complexity. In short, no theory required, only because no theory exists (yet).

<comment><USER2> Isn't that just another facet of the same concept? The property you're referring to as "intricacy" is quantifiable and scales with the kinds of problems a program solves.

<comment><USER25> How is it quantifiable? Which is more intricate, Linux or Windows? I don't think that question is answerable in any way that's meaningful. If you ask anyone that question you get a lot of qualitative descriptions and opinions, nothing definitive.

<comment><USER2> IPC boundaries, interface size, basic block count and CFG arity, number of different storage classes, number of different objects, number of different object lifecycles, &c.

I'm not saying there's one best known way to measure the complexity of a system, just that it is measurable.

<comment><USER25> These are black box metrics, better then counting lines of code, but essentially never truly able to describe the complexity of a system. To my knowledge, there's not even a strict theoretical definition describing what complexity is.

<comment><USER2> This seems like a discussion that ends in us arguing about the validity of the concept of a human soul.</comment></comment></comment></comment></comment></comment>


Haskell Is Exceptionally Unsafe  - <AUTHOR> https://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-unsafe/ <comment><USER2> The author is complaining about two language extensions which are present in GHC. These extensions are not part of the Haskell language, which is defined at <http://www.haskell.org/onlinereport/haskell2010/> .

The first language extension is the function 'unsafePerformIO', defined in the module 'System.IO.Unsafe'. It's not defined in the language spec, and is unsafe _by design_ because it's intended for very rare and specific use cases in performance-critical code.

The second language extension is the 'Data.Typeable' module, which defines a mechanism of dynamic typing. The standard way to use Typeable is to let the compiler define the instance, which is both safe and much easier to type. It's well-known that implementing a Typeable instance manually is unsafe; for example, see Oleg's post from 2007 <http://okmij.org/ftp/Haskell/types.html#unsound-typeable> .

Again, these are extensions to the language, implemented as experiments by a particular compiler. A program which uses them is no longer standard Haskell.

His code does not compile when built in standard Haskell mode:

      $ ghc --make exc.hs -hide-all-packages -package haskell2010

      exc.hs:2:8:
          Could not find module `Data.Typeable'

<comment><USER3> This is all true, but his actual point is that exception handling should not involve Data.Typeable (or any type casting) at all. I do feel this is an extremely obscure point that does not justify this hyperbole, but it is his blog and he is free to decide what is important there.

<comment><USER2> From his post, it appears that ML handles exceptions by allowing code to add new constructors to the 'exc' type at run-time. This is effectively indistinguishable from the GHC implementation of dynamic typing, which uses typeclasses.

Without some sort of dynamic type casting as used in ML or Haskell, then it's not possible to implement an exception handler that can extract information (such as type) about an exception. All you'd be able to determine is "some exception was thrown".

<comment><USER3> Yes, ML is adding new constructors to exn type at runtime, but this is different from GHC implementation of dynamic typing which uses typeclasses, because GHC does not add typeclasses at runtime. Take a look at ezyang(who is a GHC developer)'s comments in the post.

I repeat that this is extremely obscure and probably only interesting to people like ezyang. He is engaged in the discussion, so I guess the post was not pointless.

</comment></comment></comment></comment><comment><USER4> I suspect the reason why this is being upvoted and what it actually says have nothing to do with each other. This is a bit of an academic debate about very precise details of exception handling, not some sort of takedown of the Haskell hype.

In the event that you really are interested in the topic at hand, you probably ought to read the followups on [http://www.reddit.com/r/haskell/comments/y74vn/robert_harper...](http://www.reddit.com/r/haskell/comments/y74vn/robert_harper_haskell_is_exceptionally_unsafe/) .

<comment><USER5> "Like most of Harper's articles about Haskell, this is both mostly true and an elaborately constructed troll where it's impossible to tell whether he's getting some lulz or merely piqued that nobody uses ML."

Indeed.

<comment><USER6> Bob Harper is a pillar of PL research, I think the credentials of his detractor deserve just a tiny bit more scrutiny. It's one thing to refute his assertions, and it's something else entirely to dismiss them as "troll" or "butthurt".

<comment><USER7> It looks like that comment is from the author of a few popular-press PLs books (most recently _Real World Haskell_ ), so probably knowledgeable, though not Harper-level accomplished.

</comment></comment></comment></comment><comment><USER5> He should at least preface these kinds of posts with, or add something to the sidebar, that reveals that he is positively and absolutely biased toward SML: [http://en.wikipedia.org/wiki/Robert_Harper_(computer_scienti...](http://en.wikipedia.org/wiki/Robert_Harper_\(computer_scientist\))

I get an odd taste in my mouth seeing a core language contributor bashing other languages for being "inferior," whilst attempting to appear neutral.

<comment><USER8> Does that affect the validity of his arguments?

I would be more sympathetic except that I am constantly seeing a certain subset of Haskell programmers engaged in the same kind of advocacy. Should they all disclose a conflict of interest because they like Haskell?

<comment><USER5> If they contributed to the Haskell type system and they are commenting on the inferiority of the type systems of other languages, absolutely yes.

This is far from his first Haskell-bashing exercise. Take a look at the Wikipedia page for Haskell: "Robert Harper, using Standard ML to teach introductory programming, has given his reasons for not using Haskell. Among these are the difficulty of reasoning about resource usage with non-strict evaluation, that laziness complicates the definition of data types and inductive reasoning,[49]and the "inferiority" of Haskell's class system compared to ML's module system.[50]"

I'm not saying his arguments aren't valid. It's just curious that he's not attacking SML with the same vitriol, and perhaps people would like to know why.

<comment><USER8> I don't see how he is obligated to attack anything else with the same vitriol, if he doesn't see the same problems with it. It seems that we might just as well try to declare a moratorium on Haskell programmers' bashing of other languages on the basis that those other languages are not type-safe enough.

Any time someone bashes $FAVORITE, I can just disclose to everyone that they are a ${FAVORITE}-basher and therefore aren't speaking credibly. Hooray!

<comment><USER5> Surely you don't believe that SML doesn't have its own set of issues? My point is he doesn't criticize SML in the same manner on _any_ issue, for a very good reason: he helped design the language.

<comment><USER3> I believe SML doesn't have any issue that Robert Harper cares about. It is nearly perfect in all things Robert Harper cares about. Are you suggesting that Robert Harper should care about more things than what he currently cares about?

I disagree with your opinion that he doesn't criticize SML because he was involved in the design. SML is not perfect, but Robert Harper does not criticize SML because SML is Robert-Harper-perfect. Or nearly so.

<comment><USER5> What's your point?

<comment><USER3> My point is that you are seeing an ulterior motive where I don't see any.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Hm, I was expecting this to at least mention that exceptions in Haskell pure code is imprecise, and you can only guarantee the exception you desire by throwing it in the IO monad.

[http://research.microsoft.com/en- us/um/people/simonpj/papers...](http://research.microsoft.com/en- us/um/people/simonpj/papers/imprecise-exn.htm)

Although I'm not sure what the point is in the article: yes, if you write a purposefully flawed instance of Typeable, you will get errors when you try to use it. I'm not convinced that this is a demonstration that it is "unsafe", since the flawed Typeable instance seems to cause errors in the code that _uses_ the flawed Typeable instance, and not in other parts of the code.

<comment><USER8> I don't disagree. But -

> yes, if you write a purposefully flawed instance of Typeable, you will get > errors when you try to use it.

And if you write flawed C, you will also get errors when you try to use it... but I don't think that will get many heads nodding in the camp of static typing zealots.

<comment><USER10> > zealots

That word has no place in technical discussions.

<comment><USER8> The idea that static typing is better than any other tool for preventing bugs is a contentious dogma, not essentially different from iPhone vs. Android flame wars - just more intellectualized.

Don't flatter yourself that your position on a matter of hotly-argued opinion is technical and that other positions are not technical.

</comment></comment></comment></comment><comment><USER11> When he says "Exceptionally" does he mean "very much" or "relating to exceptions"? Or is it a pun and he means both?

<comment><USER12> I think he means "relating to exceptions", but it's meant to at first make you think "very much".

</comment></comment><comment><USER13> [http://research.microsoft.com/en- us/um/people/simonpj/papers...](http://research.microsoft.com/en- us/um/people/simonpj/papers/safe-haskell/)

</comment><comment><USER14> Is this a troll? I can't tell...

<comment><USER15> The title is linkbait if not trollish. However the article is just a technical discussion about the best way to implement exceptions in pure functional code. He prefers the way it is done in ML.

</comment></comment><comment><USER16> NECK BEARD VS NECK BEARD

(this article appears to have no practical implications)

<comment><USER17> Suddenly it's clear to me.

Haskell itself may be the greatest troll of all time. I'm dense, and it takes me a while to "get it". But Haskell may be such an awesome troll that even the people who implemented the language may not be in on the joke yet either.

Normally we look down on trolls. But just maybe, a troll can be so perfect that it can be admired as a work of art. Haskell may well be that instance of trolling elevated to an art.</comment></comment>


Beluga whale retrieves cell phone, returns it to tourist [video] - <AUTHOR> https://www.ky3.com/content/news/WOW-CAUGHT-ON-CAMERA-Beluga-whale-retrieves-cell-phone-509709511.html <comment><USER2> And the tourist didn't throw it again? At least one of these two knows how to play fetch

</comment><comment><USER3> Thats awesome. Reminded me of the Russian Beluga story [https://www.livescience.com/65359-beluga-whale-russian- spy.h...](https://www.livescience.com/65359-beluga-whale-russian-spy.html)

<comment><USER4> From what I understand, it's the same whale. (Not joking.)

<comment><USER5> Where/how did you gain this understanding?

<comment><USER6> This specific whale is famous in Norway

Edit: Found an English article on it here [https://www.newsinenglish.no/2019/05/03/white-whale-now- name...](https://www.newsinenglish.no/2019/05/03/white-whale-now-named- hvaldimir/)

<comment><USER7> It's a bummer an animal was used the way he was, but very pleasant the locals have embraced him :)

</comment></comment></comment></comment></comment><comment><USER8> More direct link without all the ads and clutter:

[https://www.instagram.com/p/BxFlIZpAT7a/?utm_source=ig_embed](https://www.instagram.com/p/BxFlIZpAT7a/?utm_source=ig_embed)

</comment><comment> amiga-workbench "Keep your plastic trash out of my ocean!"

</comment><comment><USER9> I want one! D: No but... Not sure I could stay in the boat if this happened, there's something with these animals that makes you want to be in there with them. Head says "it's snowing and freezing cold..." body just dives in.

</comment><comment><USER10> And the human instinct is immediately commercialize it with some group that is probably going out and filing lawsuits on some kids reposing this, its just a guess I do now nothing about them ...

</comment><comment><USER11> The instinct to want to help seems normal, natural; and examples such as this even seem to serve as a tool for reflection for the face of the modern state of humanity.

<comment><USER12> [https://www.wikiwand.com/en/Anthropomorphism](https://www.wikiwand.com/en/Anthropomorphism)

<comment><USER13> I always wonder why it sometimes seems that any kind of animal behavior that resembles human behavior needs to be rationalized away as anthropomorphism. Is it really that far-fetched to assume animals share at least some emotions and behaviors with humans?

In the end, many forms of human behavior and emotions evolved over a long long time, and way before language and culture. Why could a Beluga whale not have also evolved behavior and emotions resembling altruism, for example?

<comment><USER12> I'm sure some animals have behaviours similar to our altruism. I just don't buy that particular example as a proof of :

> The instinct to want to help seems normal, natural; and examples such as > this even seem to serve as a tool for reflection for the face of the modern > state of humanity.

<comment><USER13> Fair enough, that statement may indeed be overreaching a bit ;-)

</comment></comment></comment></comment></comment><comment><USER14> But which brand of waterproof smartphone is it? There's a bug in the viral ad.

<comment><USER4> iPhone

</comment></comment><comment><USER15> I bet it is trained to do that sort of thing.

<comment><USER6> It is! It has been trained by (probably) the Russian Navy. It escaped and now lives in Norway.

[https://www.newsinenglish.no/2019/05/03/white-whale-now- name...](https://www.newsinenglish.no/2019/05/03/white-whale-now-named- hvaldimir/)</comment></comment>


A guy scammed me, but I have his bank account number and routing number - <AUTHOR> http://money.stackexchange.com/questions/72446/a-guy-scammed-me-but-i-have-his-bank-account-number-routing-number-can-i-use <comment><USER2> In the film "House of Games" the con-artist says that all cons start by trusting the mark, showing faith in them, and doing something for them.

I _really_ enjoyed the film, and I learned something from it. The story told in this submission made me think of the film - no need to guess why.</comment>


Real-Time AI: Microsoft Announces Preview of Project Brainwave - <AUTHOR> http://blogs.microsoft.com/ai/build-2018-project-brainwave/ <comment><USER2> I understand that the big problem with FPGA and big data is that the memory bus ends up being the bottleneck anyway. So you're just left with a slow soft processor and a couple microoptimizations on the processing side. How to overcome that?

<comment><USER3> Brainwave FPGAs sit directly on the NIC of the server; every FPGA essentially acts as a 40GB/s passthru NIC to a host machine, and each one can talk to the Microsoft SDN completely on its own independent of the host CPU, in order to bind multiple devices together to create aggregate compute units. FPGAs in a server are partitioned into multiple RTL blocks (so 1 FPGA can host/execute multiple workloads concurrently, not unlike a cloud server), and the "outer" RTL simply routes messages, shuffling packets between RTL blocks, or RTL blocks on different hosts. Thus the CPU is more-or-less cut out of the fast path in a lot of cases, and acts more like a control plane.

Brainwave can deploy to hybrid FPGA/CPU topologies, however (where part of the design is on an FPGA, and part is on a CPU, and they coordinate over the SDN), so the choice of underlying accelerator is flexible and they can scale independent of available capacity.

Microsoft has effectively created a hardware microservice architecture for their large scale FPGA deployments, because the capacity is essentially elastic, and the hardware exposes miniature services that directly talk on the network and coordinate to execute large-scale jobs.

<comment><USER2> Okay so speaking of FPGA as the next gen of AI is a bit misleading? Because it's really just a networking optimization? (I ask because I am intrigued by FPGAs and a bit disheartened if that is all there is to it, not because I'm bashing anything.)

<comment><USER3> Well, any "next-gen, hyperscale AI system" at the level of Microsoft is going to be part hardware, part software, part infrastructure; the scale is simply too large these days to short-change any one of these and remain competitive.

Microsoft's network and the decoupling of the FPGA from the host machine are major aspects of Brainwave's success for them, but any successful project like this, even with different specific choices -- is going to largely be sustained off "boring" things like a solid networking backbone. Plus there are other concerns at this scale, like power usage, so just thinking of it in terms networking is misleading...

Microsoft has had major success with Brainwave and they seem committed to it, but overall the field is advancing pretty rapidly and there will be lots of competitors (not just FPGAs) in this space. And their needs and use cases are unique, so drawing generalized conclusions is a little tough.

(As a disclosure, I work on DNNs-on-FPGAs for $WORK, but am speaking generally.)

</comment></comment></comment></comment><comment><USER4> I hope Intel will offer similar capability in the future without Azure (or any other cloud provider) lock-in, with lower latencies, because you don't need to send data to outside your facility.

<comment><USER3> Dell is now selling rack unit servers with Intel FPGAs installed (Arria 10 line). But you're not going to get the software stack that backs Brainwave without serious work on your own...

</comment></comment><comment><USER5> Google I/O starts tomorrow. Coincidence?

<comment><USER6> Microsoft Build is this week as well (the keynote is going on as we speak). Facebook F8 was last week. I guess this is developer conference season?

<comment><USER5> Ah, thanks. I'm actually not in that world, so the general conference schedule didn't occur to me.</comment></comment></comment>


A New Development for Coverity and Heartbleed - <AUTHOR> http://blog.regehr.org/archives/1128

<comment><USER2> Interesting approach! Kudos to Coverity for jumping on it so quickly.

Taint analysis is notoriously prone to false positives; as well as the reasons listed in this post, there are many situations where relations between variables mean that tainted data doesn't cause problems. [For example, the size of the memcpy target (bp) is known to be greater than payload; so even though payload is tainted, there isn't a risk of a write overrun.] But even noisy warnings can be very useful — when we first implemented simple taint analysis in PREfix a decade ago, the first run was 99% false positives but one of the real bugs we found was in a system-level crypto module. So with the increased attention to these kinds of bugs after Heartbleed, seems like a great time for more attention to these classes of bugs.

<comment><USER3> >first run was 99% false positives but one of the real bugs we found was in a system-level crypto module.

Thinking of it as a false positive seems like the wrong perspective. The static analyzer is a tool that flags usages that are not proven to be correct. The fact that it turned out to be valid isn't the issue, the issue is that your code did not prove it valid to the satisfaction of the analyzer. This isn't necessarily a failing of the analyzer, but an indication that your code should be written in a different way, or provided more "evidence" that its correct (i.e. if guards/size checks).

The goal should be to write code in such a way that whatever tool you're using can prove it correct. Sure, the better the tool the easier this process is. But we really need to fundamentally rethink how we approach this problem.

<comment><USER4> I was once talking to someone with a lot of experience in this field and he said that false positives were one of their biggest problems. If you have too many false positives programmers end up deciding the analyzer is full of crap and either dismiss the results entirely or gloss past many ultimately useful results.

A static analyzer that will actually be used can't have too many false positives, and this is the big challenge with these things. He said that allowing some false negatives (to cut down on false positives) made the tools more effective in actually solving problems.

That said, with something like openSSL, you do sort of just wish the programmers would deal with it. Language design should include elements to make these sorts of static analyses easier.

<comment><USER3> That's an interesting idea, to have a language and a static analyzer created for each other simultaneously. Constructs that are hard for a static analyzer to reason about would be left out (or relegated to an "unsafe" context). I wonder if there's any work regarding seeing how well rust holds up to the state of the art in static analysis?

</comment></comment></comment></comment><comment><USER5> > additional locations in OpenSSL are also flagged by this analysis, but it > isn't my place to share those here.

Why do I get the feeling that we're going to see three months of new OpenSSL vulnerabilities, like we saw with Rails last year? I'm sure Heartbleed plus all the bad press about code quality means a lot of people are suddenly looking. Assuming there is more to find, does anyone have any advice for how we might prepare for it?

</comment><comment><USER6> In case you want to try out static analysis on your own code-base, here's a link with the list of most popular tools in this field, grouped by language: [http://en.wikipedia.org/wiki/List_of_tools_for_static_code_a...](http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis)

<comment><USER7> Visual Studio now ships with a reasonably good static analyzer built in. We're using it more than our aging copy of PC-Lint.

(Carmack's review: [http://www.altdevblogaday.com/2011/12/24/static-code- analysi...](http://www.altdevblogaday.com/2011/12/24/static-code-analysis/))

<comment><USER8> VC++ analysis is useful aside from the fact that it mistakenly thinks every pointer usage is a potential null pointer, but I've gotten better results with clang static analysis.

<comment><USER9> Every pointer _is_ potentially null, until proven otherwise (which in the general case means solving the halting problem).

</comment></comment></comment></comment><comment><USER10> Interesting: "As you might guess, additional locations in OpenSSL are also flagged by this analysis, but it isn't my place to share those here."

<comment><USER11> Anyone know if these have been bug reported?

<comment><AUTHOR> Not yet, we are looking at them right now.

</comment></comment></comment><comment><USER12> It's super cool to see the power of advanced static analysis these days. Props to the Coverity team for using the Heartbleed trainwreck to motivate new research on these problems.

That said, are there other ways to fix this class of problem? We have choices. We can continue to build ever-more-advanced tools for patching over the problems of C and C++, or we can start using languages that simply do not have those problems.

There will always be a need for C and C++ in device drivers, microcontrollers, etc. But there's no compelling reason why SSL implementations in 2014 should use languages designed to run on mainframes in 1973.

<comment><USER13> Well, usually this stuff is written in C because other languages come with big runtimes that make them unsuitable for utility libraries that need to be callable by everyone and from everywhere.

That said, we're of course working on changing that with Rust. But I should note that memory safety without garbage collection is just _hard_ : it requires the entire language design to be balanced on a delicate precipice. It's not surprising that it's taken a long time to get there.

<comment><USER14> > But I should note that memory safety without garbage collection is just > _hard_ : it requires the entire language design to be balanced on a delicate > precipice.

I was thinking about this recently and I think a large part of the problem is that C arrays are too weakly typed. Array should be a different type than pointer and they shouldn't be convertible. In particular, you shouldn't be able to subscript a pointer, and the in-memory representation of an array should begin with its length. At that point the compiler can include a runtime bounds check for every array access that it can't prove is safe at compile time.

<comment><USER15> >runtime bounds check

The reason people use c, is to get higher speed by avoiding those kinds of checks. A real solution most avoid slowdowns.

<comment><USER16> If the reason was to avoid those checks, then people really don't know better.

Turbo Pascal => {$R-}

Ada => pragma Suppress (Index_Check);

Modula-3 => cm3 -A

D => dmd -fnoboundscheck / array.ptr[index] in @system code

Just a few examples. Additionally there are lots of research how to remove bounds checking in compiler optimizations

[http://citeseer.uark.edu:8080/citeseerx/showciting;jsessioni...](http://citeseer.uark.edu:8080/citeseerx/showciting;jsessionid=749D9B8FE7B1755974DA5561D1926781?cid=71083&sort=cite&start=10)

What C has going for it is the symbiotic relationship with UNIX, 40 years of optimizations in most compilers and the historical baggage of being around for so long.

Other better languages suffered from having been shown the door as UNIX spread into the enterprise, but there was a time when C compilers didn't generate better code as the other ones.

</comment></comment></comment></comment></comment><comment><USER17> Is this implemented in Coverity by a local model? (There is reference to a model being applied) Or was the actual product modified to support this? Can Coverity customers get ahold of this now?

<comment><AUTHOR> The "model" makes reference of the model injection for memcpy.

The modification made by the team is referenced in John's blog post "Their insight is that we might want to consider byte-swap operations to be sources of tainted data".

As Andy said (and quoted), that's a modification that we need to evaluate overall to look at its impact in term of false positives (FP). It will probably be made available however under some options if it doesn't pass our acceptance tests for FP rate though... a bit too early to say.

<comment><USER17> Thanks, I was just curious if customers could play with these kind of experiments if they understood the FP potential. I really like Coverity's output and always like new ways to tease out potential bugs.</comment></comment></comment>


America's aggressive use of sanctions endangers the dollar's reign - <AUTHOR> https://www.economist.com/briefing/2020/01/18/americas-aggressive-use-of-sanctions-endangers-the-dollars-reign <comment><USER4> For the rest of the world this is a good thing.

Why would the United States be the one to decide if Germany is allowed to build a pipeline to Russia or not?

Image if it was Germany that used sanctions to prevent the US from building a pipeline to Mexico. Would you be ok with that?

<comment><USER5> The United States' main geopolitical imperative is to maintain global hegemony. Part of this is ensuring regional powers are either allied (in the case of NATO countries or Saudi Arabia) or contained (in the case of Russia and Iran).

It is a fundamental rule of Geopolitics that every country assert itself to the best of its abilities with the strengths they have. One of Russia's biggest strengths is natural resources. It is advantageous to them to have Western Europe dependent on its oil and natural gas supplies.

George Friedman explains in this book [1] that Russia may attempt to assert itself to a greater extent in the next few decades, possibly going so far as to annex a Baltic country or two. Today this would be inconceivable, but if Russia has the off switch for Germany's economy, NATO's response is drastically weakened.

Whatever scenario may come to pass, European reliance on Russian natural resources disrupts the US's containment strategy which it needs in order to maintain its dominant position in the region. So yes, it will say something if it feels like that is under threat.

Not saying this is a good or bad thing. Depends on your perspective and what country you live in.

[1] [https://www.amazon.com/Next-100-Years-Forecast- Century/dp/07...](https://www.amazon.com/Next-100-Years-Forecast- Century/dp/0767923057)

<comment><USER6> "United States have no geopolitical strategy, but a lot of self proclaimed geopolitical strategists."

I once have heard this position from US ambassador in Kazakhstan on a private reception event.

The guy told people he expected a visit to a *stan country to be like a visit to a warzone.

He was learning martial arts, hostage negotiation, and been mentored by multiple self proclaimed experts on "warlord politics" of the region.

There was no end to his disappointment when he came to understanding that all that geopolitical BS he learned was for nothing, and he came to station the most boring post-Soviet hillbilly town.

I think most Americans, even the most educated ones tend to greatly overthink "geopolitical conspiracies"

Ex-USSR fiefdoms, Russia included, are ran by very simple people, without any geopolitical ambitions.

For them, blackmailing Germany and other wealth nations in Europe by threatening to close the tap has no political story to it at all, just plainly a way to extort some extra bucks, and show the world how big their balls are.

<comment><USER7> _> Ex-USSR fiefdoms, Russia included, are ran by very simple people, without any geopolitical ambitions._

The people of Georgia, Crimea, and the rest of Ukraine would beg to differ.

<comment><USER6> How to say... Russians invasions are acts of war, squarely and simple, but they do so without any tinfoil "geopolitical conspiracy" in mind.

There is no bigger "grand plan" to them than to an 8th century Viking raid: more subjects, loot, and territories to use to stage further invasions.

Danes cared more for how tasty the British were, before they started to care about the British throne and court politics in the bigger Post-Roman world.

<comment><USER8> The conquest of Crimea was probably more about providing a distraction for domestic audiences than anything else?

<comment><USER9> The "conquest" of Crimea was a response to an implied threat to a natural gas trade with Europe in the followup of a western-sponsored coup.

(to be even more specic, Crimean events were mostly about regaining the control of the Black Sea Fleet naval base, while Donbass events were about reacting to a hostile coup, but the two things are closely related)

It was also an object lesson to all the minor powers in the region: you cannot take US money to have a small victorious colour revolution anymore. Not in Russia's backyard.

edit: oh wow downvotes, I am so surprised /s

<comment><USER10> Please don't go on about downvotes. It's against the site guidelines, is tedious, and usually turns out to be wrong. In the end your post got almost no downvotes relative to upvotes.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> It also endangers the basic principle of a rules-based, open world.

If you think that's a good idea, imagine what happens to an economy when civil law and contracts are not enforced, even without any threat of violence.

To pick just one example: if you're trying to get a loan to build a factory or buy a house, it's _good for you_ that there are laws and trusted courts that would cause you a whole lot of pain if you failed to repay.

It's no different in international politics, only that treaties between states are backed not by some external force, but by each country having a strong interest in remaining within that system that outweighs any short-term benefits from skirting its responsibility.

I guess some of this is mildly counter-intuitive. But really there is game theory far more complex than this regularly understood on primary school schoolyards.

<comment><USER12> There's no such thing as a rules-based, open world. International relations is a state of anarchy and perpetual conflict that only fleetingly resembles peace during those periods where there's a global hegemon that can enforce those "rules". Within a country, those courts are the hegemon.

"Each country having a strong interest in remaining within that system that outweighs any short-term benefits from skirting its responsibility" was the theory prior to 1914 as to why the Great War would never actually happen.

<comment><USER13> > There's no such thing as a rules-based, open world.

You're living in one right now. Anarchy need not be synonymous with chaos, especially if disputes and conflicts are relatively unimportant (due to easy defense making 'rights' self-enforcing). The point of courts is then to arbitrate disputes in a publicly-visible way, enforcement is relatively less important.

<comment><USER14> The only reason courts have authority to arbitrate disputes is because they are backed up by the will and authority of the government, which in turn has a monopoly on the use of force in society.

<comment><USER15> Now you are bumping on the reason I think the founders put the 2nd amendment in the bill of rights. Govts have to be balanced at some point by the will of the people

<comment><USER16> Of course that's the reason. Different people use different euphemisms, for the same reason we do now. ("Defend against tyranny.") But we're talking about an amendment the founders wrote shortly after they took up arms to overthrow their government. It's clear what they were talking about: [https://www.nationalreview.com/2015/04/second-amendment- hist...](https://www.nationalreview.com/2015/04/second-amendment-history- lesson-times-ted-cruz/)

> Before a standing army can rule, the people must be disarmed; as they are in > almost every kingdom of Europe. The supreme power in America cannot enforce > unjust laws by the sword; because the whole body of the people are armed, > and constitute a force superior to any bands of regular troops that can be, > on any pretense, raised in the United States.

That was Noah Webster, dictionary guy. He's clear that the second amendment embodies a personal right to bear arms (so the citizens aren't disarmed, like in Europe) so they can overthrow the government.

<comment><USER13> Note, the point is not to overthrow the government in any real sense, but rather _to make it incredibly costly and perhaps outright infeasible for the government to actively use state-organized violence against its own people_ , as dictatorships everywhere are wont to do. Combine an armed populace with a strong tradition of being loyal to the Constitution and its principles first and foremost, _even in the context of a standing army or similar_ , and it's especially clear what the 2nd Amendment was supposed to achieve.

<comment><USER17> The federal government is light-years ahead of whatever private citizens can get their hands on; 71% of americans are overweight or obese; 30% of americans have some kind of chronic pain.

If a shooting war broke out between the federal government and private citizens, the National Guard would just steamroll right on through them like they were made of thin air.

I think that the best way to exercise the second amendment is to organize militias at the state level, but even then, there still isnt enough cash for proper defenses against the federal government.

<comment><USER13> > ...the National Guard would just steamroll right on through them...

Even assuming that they _could_ do this (which is plausibly quite wrong, as defense tactics can be very effective), what's the incentive? The people who serve in the National Guard _are_ citizens themselves (who have sworn to uphold the Constitution) and every bit of effective defense makes it that much easier for them to defect while keeping plausible deniability. By contrast, if you've confiscated all the guns away (or bought them back) that dynamic just can't happen, at least not nearly as easily.

The presence of an armed citizenry _does_ make for a huge difference in this scenario. No doubt about it.

<comment><USER18> Their incentive would be a manufactured one, painting the citizenry as part of some conspiracy/extreme party etc. Just look at how many Republican news outlets continuously portray the other side as extreme and crazy and dangerous.

Just having possession of armed weapons makes absolutely no difference to a modern, well equipped American military force. We're talking about Armored Personal Carriers and Tanks rolling through cities, all communications being monitored or cut off. The arms may make it hard for the occupying force as there will be more shootouts but retributions will keep most of the populace under control.

The dynamic of Armed militias being a deterrent to a military occupation made sense in the 18th century but don't make much sense today.

<comment><USER16> > We're talking about Armored Personal Carriers and Tanks rolling through > cities, all communications being monitored or cut off.

Assad literally used tanks against the civil uprising, and wasn't able to stop it. (And doing so caused part of the army to defect.) Gaddafi was killed by the National Liberation Army, which initially armed itself by capturing tanks and weapons from military stockpiles.

<comment><USER18> Was either the Libyan or Syrian populace armed to the teeth? Did the availability of weapons (or the lack thereof) have any impact on what happened?

Comparing Syrian and Libyan military forces to American ones is also a stretch. We're talking about orders of magnitudes of difference in armaments and intelligence.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Whether China's yuan should be freely convertible to other currencies is something the PRC has struggled with for years. A freely convertible yuan would increase China's influence on the world financial system, but it would also increase the influence of the world financial system on China. And it would require much easing, if not elimination, of China's exchange controls.

A decade ago, a freely convertible yuan was seen as likely. But China has backed off from that. Xi Jinping's "China 2025" is about autarky - <USER2> China's dependency on the rest of the world.

So, the yuan as a world currency isn't really happening yet.

Euros, though...

<comment><USER20> The yuan won't be freely convertible because that would open the floodgates to capital flight from China. As long as that possibility exists, free convertibility will not.

<comment><USER21> Yeah, on top of the issues of infrastructure around payments/settlements/collateral management/kyc laws that often go ignored in these discussions as well as the high correlation of lowering (euro)dollar usage globally with lower global growth rates… ideally you'd have higher growth rates with lower (euro)dollar usage if there was any serious alternative.

Fundamentally speaking, I think non CB backed cryptos (combined with hedging tools via futures/options/swaps/ndfs/etc) have a better chance because they can be used to lower the costs intl of payments/settlements/etc, esp in these times when the trust in central banking becomes more and more contested. But I only see this happening slowly until there's a catalyst to push this to the next level.

<comment><USER22> I would expect cryptocurrency to ascend in a series of hops, "chaos is a ladder" style. Every time a central bank somewhere takes home their toys, crypto will click forward.

<comment><USER21> Yeah, that's probably a better way to put what I think I wanted to get at.

</comment></comment></comment></comment></comment><comment><USER23> The lack of any viable alternative has kept the dollar in its current dominant position.

That alternative won't exactly announce itself so that US policymakers can rationally decide to change course about the weaponization of money.

It will instead, sneak up on the country in the form of weird little experiments that don't seem worth the time and effort to track or regulate. By the time one of them becomes the obvious marketplace disruptor, the die will have been cast.

<comment><USER24> Isn't the answer the euro? Stable, inflation proof, light or no sanctions. As brexit proceeds and more financial services move to mainland Europe, you won't even have to worry about the brits messing with it...

I seem to remember the EU agreeing to setup a psudo bank to deal direct with Iran so they can bypass restrictions on trade?

Edit: here it is! [https://www.google.com/amp/s/amp.dw.com/en/eu-mechanism- for-...](https://www.google.com/amp/s/amp.dw.com/en/eu-mechanism-for-trade- with-iran-now-operational/a-49407662)

<comment><USER25> Didn't the whole Greece debt situation show why that could be a problem? One country's debt crisis caused the euro to tank 30% in a very short time. It ended up rebounding, but pretty much forced the EU to handle the situation (write off debt and provide low interest loans for the rest) or risk the whole thing exploding.

It seems like your betting on 5-10 countries not failing, when with most currencies you just have to deal with 1.

Which is probably why it's not currently the reserve currency, one would assume.

<comment><USER6> Greece was fiasco for Euro.

It's a lesson learned now, and ECB will hold binge spenders on a leash.

UK can leave EU, Greece or Eastern Europe can not.

<comment><USER26> It's more that the Euro has been a fiasco for Greece, Italy, Portugal and Spain... It's fundamentally problematic to have a single exchange rate between countries with different inflation rates, balances of trade, etc. - <USER3> you can't have an exchange rate that works for everyone and the value can't move between the other economies to balance out the differences.

The only way around that (apart from going to separate currencies with floating exchange rates) is to have some kind of fiscal balancing method. In the US, for example, federal taxing and spending tends to do this between the states. But that is probably politically impossible in the EU (redistribution from richer countries to poorer is pretty unpopular).

<comment><USER6> Very easy to do, and that's actually what ECB is now doing as I understood.

They now enforce the limit of how much debt a country can sell, and at what terms much more rigorously

</comment></comment></comment></comment></comment></comment><comment><USER27> James Rikard (author of Currency Wars) in his newest book Aftermath predicts that the dollar's reserve currency run may soon be over, and special drawing rights (SDR) reserve currency might only be 1/3 dollars. I think he is probably correct on this prediction but maybe not on another prediction: currencies like China's and Russia's might soon be 20% backed by gold. He makes the point that there is no need for 100% backing from gold since a smaller percentage would still prevent a country from printing new currency out of thin air.

I think the dollar has a lot of inertia so it might reign for a long while longer as reserve currency, but then I also think about how much debt we have. Our treasury can not account for $21 trillion (ref: Catherine Austin Fitts [http://solari.com](http://solari.com)) and the amount of consumer, educational, real estate, etc. of debt worries me, but: I expect a slow burn of our economy, not falling off of a cliff, economically speaking.

We can adjust to a decade long slow downward economic trajectory, people are resilient.

<comment><USER28> What would happen to life in the US if the dollar was no longer the global reserve currency?

<comment><USER27> I think it would put us on par with other countries, we would lose a nice advantage. Worst case scenario would be a sharp economic decline, but I optimistically think it would be a slow leveling out, a slow decline in consumer purchasing power, limit government expenditures, etc. But, I am not at all sure what will happen.

<comment><USER28> Do you think that hostile foreign nations are actively trying to end the run of the petrodollar?

<comment><USER27> I think the point of the original article is yes, it is in some other countries interests to end the dollar being the sole reserve currency.

On the other hand, the USA provides stability, so everyone who is rational in the world should want any transition to be slow. The whole world is in this together, I think we prosper together, or suffer together. Let's hope for the first option.

</comment></comment></comment></comment></comment><comment><USER29> I just read a related article the other day, claiming the same thing, but with a different analysis: [https://mises.org/wire/world-looks-abandon-dollar-us- sanctio...](https://mises.org/wire/world-looks-abandon-dollar-us-sanctions- tighten-their-grip)

<comment><USER30> Ha Ha mises.org. What a joke! An institution which has been wrong about everything for the past 100 years is predicting a dollar cash? What a surprise!

</comment></comment><comment><USER31> As a point of fact, it isn't true that the dominant currency imposing costs is new...that has always happened. Britain did it in order to secure continued use of the £, and the US has done it before now. It is a normal extension of foreign policy (because finance is not separate from politics, as the Rusal example shows).

It isn't some kind of authoritarian aberration either. The point is that the US has most to lose from a system of free trade so is the one who shoulders most of the burden for securing it. You don't secure something by sitting back and letting people ride all over it.

And yes, some people who don't want to play by those rules will grouse. But the system will always lean towards one dominant currency, it is just easier that way (the UK losing control was was unexpected and took nearly six decades to play out after the point of obvious decline). The world is awash in dollars, no need to worry (if anything, the issue is that some are too reliant on too much dollar funding...not that the world is moving away).

It is kind of unfortunate that the Economist keeps getting worse. The election of Mango Man and Brexit has truly addled the minds of some generally smart people (or made clear that their smartness wasn't actual intelligence but an ability to just parrot whatever they were told was "right").

<comment><USER32> I'm not sure I get your argument. It doesn't appear the Economist article is claiming that the dominant currency has only just started imposing costs.

Their claim is that the recent increased costs, and more relevantly their almost arbitrary nature, hasn't just led to the usual suspects grousing, but has also started causing allies who didn't grouse in the past, to actively seek and build alternatives.

As a result, the USD may potentially lose its status as the dominant currency much sooner that it may have otherwise.

<comment><USER31> Yes, the main contention of the article is that this is unusual. If you think it through: the only way this article makes sense is if that claim is made...otherwise, the US was doing this in the past and it made no difference (which is true).

I think you are taking a slightly expansive definition of ally. You are referring to the EU? A significant grouping within the EU does not regard the US as an ally (particularly economically, ref France bringing down Bretton Woods...the US is the giving tree here, the more you give, the more the EU takes)...and all of the people grousing are the usual suspects (China, Juncker, etc.).

And no, you need to justify an extraordinary claim with extraordinary evidence. None of this is even remotely extraordinary (and counter to the fairly obvious evidence of the dollar's position growing...not receding).

</comment></comment></comment><comment><USER33> The dollar's exceptional liquidity makes it more valuable, which is good for people who have dollars, but it's bad for people whose costs are in dollars (American exporters). The dollar's strength since the earlier 1980s (the first major flight to liquidity during the era of free movement of capital) has been terrible for American industry. It's like Dutch disease, but instead of a commodity like oil causing unbalanced trade, it's the dollar itself.

</comment><comment><USER34> It's not about whether dollar sucks in absolute terms. It's about whether it sucks less than other currencies. It's tied to the largest economy in the world, and the strongest military in the world (importantly, including the strongest navy as well), by quite a margin, and as such, it's not going anywhere. You don't need to run faster than the bear, you just need to run faster than the other guy.

</comment><comment><USER35> This is an interesting article, but exposes the Economist's bias and lack of an honest historical accounting. While the it is new, interesting, and important that the world is becoming more skeptical of the dollar, it is kind of laughable that the only reference to Iraq and sanctions is the ones that were in the news recently.

Iraq and many other countries have been subject to crippling US sanctions many times in the past. In the 1990s, sanctions were issued by the Clinton administration that were so severe that hospitals were scrubbing the floors with gasoline ([https://theintercept.com/2018/03/21/us-war-iraq-legacy-of- bl...](https://theintercept.com/2018/03/21/us-war-iraq-legacy-of-blood/)).

[https://reliefweb.int/report/iraq/iraq-study-baghdad- hospita...](https://reliefweb.int/report/iraq/iraq-study-baghdad-hospitals- highlights-critical-needs)

"In June, 1991, Medicine For Peace medical teams began working in Baghdad pediatric hospitals. The following is a description of what they found:

"The hospital was in darkness. Ventilators, incubators, dialysis machines were not functioning and any patients dependent on these support systems had died. We made ward rounds with Iraqi physicians, many trained in the US and Great Britain, who were despondent and demoralized. No x-rays, lab tests, or possibility of surgery. Worse of all, intravenous fluids and supplemental feedings for the scores of malnourished children were in short supply, the pharmacy had exhausted its store of antibiotics for treatable infections, and there was not one vial of morphine to relieve the pain of children suffering with tumors on the cancer ward."

Outside of the US, economic sanctions of this magnitude are often regarded as war crimes. They are routinely deployed against the populations of official US enemies and have been for some time under the theory that if we make life as bad as possible for the people, maybe they'll overthrow the regime. Hint: It usually doesn't work and the regime uses the sanctions to (correctly) characterize itself as under attack by foreign enemies.

In the modern instance, the case for sanctions in Iraq can only be described as barbarous bullying. The Iraqi government voted to remove US troops in response to an unprovoked assasination on an Iranian top general on their soil while performing what is claimed to be a diplomatic peace mission (another war crime). In response, the US employs sanctions to bully the Iraqis into acquiescing to an unending occupation that they have judged does not serve their interests.

Yanis Varoufakis, the Greek Finance Minister (paraphrased, talking about austerity in Greece) said that where they used to use tanks, they now use banks. In the case of Iraq, sadly, tanks, banks, and aerial bombing have all been used in various combinations at various times.

<comment><USER7> The modern instance has far less apparent rational motives. The threat of imposition of sanctions on Iraq is coming almost solely from the President of the US, framed as a retaliatory gesture. The language used implies the threat is guided primarily by emotion rather than by a sober _realpolitik_ diplomatic move.

It appears that most of the government, even most Republicans in Congress, disagree with the idea. Though Republicans are currently in a vulnerable state with regards to political pressure from the President, I find it unlikely that a bill imposing sanctions will be enacted without a significant change after the 2020 elections.

<comment><USER32> The other major change is that under the current administration America has been pointing its financial weapons at allies as well.

That's the major change the article is talking about, without being fully explicit about it. Russia and China have been wanting to move away from the dollar for over a decade.

It's the fact that the EU now also wants to do so that has changed.

The greatest long term impact of Teump's Iran policy will likely be the creation of Instex (or more relevant, whatever follows it) that will help the EU and Asian countries move away from the US as the center of the financial world.

</comment></comment></comment><comment><USER36> Ever since I saw Ray Dalio's video about the economy and long term debt cycle I have been really worried.

The thing that scares me more is that we don't hear any politicians talking about this stuff. In particular presidential candidates. The only one that seems to actually understand technology and the economy (Yang) is proposing an increase in entitlements, although hopefully the VAT can improve revenue somewhat. I know he knows who Ray Dalio is since he mentioned his name.

I think there needs to be a plan for an international system that is not dominated by one country like the US dollar and is technologically sophisticated. Some kind of multi-government backed cryptocurrency, possibly paired with a decentralized resource tracking system.

I feel like there are a bunch of people who think there is no problem and a bunch on the other side who think the situation is dire. My guess is that there is a real situation that we have to plan for and it seems like a very bad idea to put off that planning.

</comment><comment><USER37> Sanctions are the modern equivalent of siege warfare- using starvation as a weapon. I'm not sure why it's looked upon as being a kinder, gentler approach than dropping bombs on civilians. It's still violence. People still die.

</comment><comment><USER38> There's the possibility that the USG believes the dollar's primacy is going to come to an end in the relatively near future. There are other factors at play that could weaken the dollar's status that matter more than sanctions, including:

(1) The geopolitical shift away from a unipolar world, with the rise of states such as China.

(2) The upcoming end of the petrodollar, as nations shift to renewable energy.

If you believe the reign of the dollar will come to an end anyways, you might as well use its power while you have it and throw sanctions around to weaken your rivals.

<comment><USER22> This possibility comes along with the rise of a new political brand for the Republicans: "We do whatever we have to to get ours". In the early stages under GW Bush/Rumsfeld this was the lighter "We do whatever we have to to advance American interests throughout the world" but under Trump/Murdoch it is now "advance the interests of those who are loyal to me".

That will play well in an economic crisis. I don't think the brandmakers for liberalism in America are prepared for that fight. Right now the brand on the left is something like "we can and should demand a better wage and better benefits from Daddy!" but that falls flat in a crisis.

That all said, we're not in that crisis yet. So perhaps it's fine to focus on the present, where we certainly have the money to increase workers benefits.

</comment></comment><comment><USER39> I read a paper on the implementation of oil trade based on an independent crypto currency backed by Oil exporting countries, the author laid all out and how the US will never allow that to happen, sorry I lost the page source.

</comment><comment><USER40> In reality it does not although would be nice if there were good alternatives.

</comment><comment><USER41> Yep that wall has broken down. There are already long term implications to Trump craziness. What ever he is doing is extremely short sighted and plays right into China's hands, the one thing he is railing against.

</comment><comment><USER42> This is behind a paywall. Does anybody have the full article? The first few paragraphs say nothing more than the title.

Edit:

[https://archive.md/gbAv6](https://archive.md/gbAv6)

\</comment><comment></comment><comment>-

Maybe this will finally push towards crypto-currencies. Bitcoin doesn't seem to be a candidate though. 10 minutes for a transaction is too slow.

</comment><comment><USER43> If you were getting a paywall like me, just delete all your economist.com cookies and block all javascript.

<comment><USER44> Oftentimes, just pressing the 'reader' button in Firefox works.

<comment><USER43> Interesting, I will try that the next time, thank you!

</comment></comment></comment><comment><USER45> I prefer sanctions a thousand times over war.

Don't we have enough of the endless wars (Afghanistan, Iraq, Libya, Syria, etc. from the last 2 administrations?

<comment><USER46> Sanctions can be just as deadly as warfare, though, and they almost exclusively affect civilians, and don't get nearly as much media attention as warfare. From [https://caitlinjohnstone.com/2019/06/23/starvation- sanctions...](https://caitlinjohnstone.com/2019/06/23/starvation-sanctions- are-worse-than-overt-warfare/)

"Starvation sanctions kill people. Tens of thousands of Venezuelans have reportedly already died as a result of this administration's relentless assault on their economy; those human beings are no less dead than they would have been if the US had killed them by dropping cluster bombs on Caracas. Yet these deaths have received virtually no mainstream media coverage, and Americans, while they strongly oppose attacking Iran militarily, have had very little to say about Trump's attacks on the nation's economy. The economy which people use to feed their children, to care for their elderly and their sick.

I'm titling this essay "Starvation Sanctions Are Worse Than Overt Warfare", and I mean it. I am not saying that starvation sanctions are more destructive or deadly than overt military force in and of themselves; what I am saying is that the overall effect is worse, because there's no public accountability for them and because they deliberately target civilians.

If the US were to launch a barrage of Tomahawk missiles into an Iranian suburb with the goal of killing civilians, there'd be international outrage and the cohesion of the US-centralized power alliance would take a major hit. Virtually everyone would recognize this as an unforgivable war crime. Yet America will be able to kill the same number of civilians with the same deliberate intention of inflicting deadly force, and it would suffer essentially no consequences at all. There's no public or international pressure holding that form of violence at bay, because it's invisible and poorly understood."

</comment></comment><comment><USER47> The dollar is still reigning? News to me.

</comment><comment><USER48> No s.. Sherlock. It is starting to look more like a tantrum.

</comment><comment><USER49> I guess this is good for bitcoin! Good enough liquidity, can't be blocked, many tumblers, cheap transactions - maybe it will become a preferred way for international settlements, replacing gold?

</comment><comment><USER15> Given the amount of global debt does it really matter ?

[https://www.cnn.com/2020/01/13/economy/global-debt- record/in...](https://www.cnn.com/2020/01/13/economy/global-debt- record/index.html)

Its like the world is playing musical chairs and at some point the music will stop and not everyone will have a seat

<comment><USER50> Thats not how global debt works.

<comment><USER51> I'm pretty sure it does. The more debt increases against a property, the more valuation is boosted since the price of the unique property is bundled with the debt.

This is how nations have been looking at debt for some time. Yeah, you can make a margin call on the US (directly or via a partner), but what are you going to replace that resource pipeline with?</comment></comment></comment>


X86 is a high-level language - <AUTHOR> http://blog.erratasec.com/2015/03/x86-is-high-level-language.html#.VRLn95PF_XE <comment><USER2> The author's conclusion that side channel attacks are unpreventable because x86 instructions execute in a variable amount of time does not follow.

Side channel attacks that rely on variable instruction timing rely on _content-dependent_ timing. For example, the time spent for a mov from a memory location does not depend on the contents of the memory, but it does depend on the address of that memory. If that address is a function of the key or plain text, then the mov will leak sensitive timing information. If not, then the mov will not.

None of the author's various examples have anything to do with side channel attacks. The fact that xor eax,eax is just a register operation doesn't mean it can leak sensitive information.

<comment><USER3> > The fact that xor eax,eax is just a register operation doesn't mean it can > leak sensitive information.

AIUI tfa's point is that you can't assume that

xor eax,eax

and

xor eax,ebx

take the same amount of time, because "x86 is a high level language". Similarly for his other examples. This, he claims, makes it difficult to write code that resists timing attacks, if you ever want to have a branch that does nothing. Thus the discussion of cmov.

<comment><USER4> Can someone explain to me why you wouldn't just count clock ticks at a higher level than the CPU? If the operation finishes early just... wait. I understand resolution and yes you'll probably only be w/i a delta of some sort, but isn't that the point?

Why wouldn't that approach work?

<comment><USER2> Even if you could figure out the worst-case timings and how to simulate them in all cases, the performance would be unacceptable. The usual operations that are data-dependent in crypto algorithms are mov with a data-dependent address, and conditional jump with a data-dependent condition. To slow these down, you'd have to simulate the absolute worst case, which means no caches of any kind, which means possibly thousands or even millions of cycles (to simulate a page fault from disk) for every operation of unknown duration. Crypto would become infeasible.

There are much better ways to achieve this, by always computing both sides of a (logical) branch or using computation instead of branching or table lookups. You likely have to write this in assembly to be sure that the compiler doesn't "optimize" any of your tricks back into branches. Some of this is hard in older crypto algorithms (AES was designed to use table lookups in software), but newer crypto algorithms are much more amenable to safe implementation.

</comment></comment></comment></comment><comment><USER5> "high level" doesn't refer to how it is implemented.

Even a RISC instruction set can be implemented by, say, either some very slick silicon gates, or by an emulator written in Javascript.

The existence of the Javascript emulator doesn't make the RISC instruction a high level language, on the grounds that an instruction like "ADD R1, R2, R3" triggers a complicated traversal within the Javascript code.

The "level" of a language should refer to the "abstraction level". Years ago, I came to favor the definition of "abstraction level" given in the glossary of the Tunes project:

[http://tunes.org/wiki/abstraction_20level.html](http://tunes.org/wiki/abstraction_20level.html)

<comment><USER6> I think that's the author's point: x86 is now a significant abstraction from the actual details of execution.

<comment><USER7> That's true of all superscalar machines. That's what killed RISC. The original idea of RISC was one instruction per clock and a very simple CPU control section. Early MIPS CPUs realized that.

Then superscalar came to microprocessors with the Pentium Pro. It took 3000 engineers at Intel to design that CPU, but it did much better than one instruction per clock while still handling all the weird cases in x86 instructions. As the fabs improved, the Pentium Pro technology moved to the mainstream. The Pentium II and III were Pentium Pro architecture.

This killed the basic advantage of RISC. The "all instructions the same length" concept really killed it - it meant 2x code bloat. That meant bigger caches or worse cache performance. It meant more RAM and more RAM bandwidth or worse memory performance. The x86 instruction set, for all its faults, is compact.

For the crypto problem, the trouble is that modern crypto algorithms are not branch free. DES was. Vernam was. Rotor machines were. RSA and elliptic curve stuff, no. This is independent of the CPU architecture.

<comment><USER8> RSA is not "modern".

Modern elliptic curves are chosen with side channels in mind. You won't find data-dependent branches or look-ups in straightforward implementations of Curve25519 scalar multiplication, for example.

<comment><USER9> > You won't find data-dependent branches or look-ups in straightforward > implementations of Curve25519

As it was pointed out already starting since Pentium 4, for example, the same assembly instruction "add dest, src" might take a different time depending on the value of dest and src.

Unless those modern elliptic curve compensate for specific models of CPUs they run on, their straight C and assembly code might behave as if it has data dependent branches.

<comment><USER8> Are you talking about this paper? [https://gmplib.org/~tege/x86-timing.pdf](https://gmplib.org/~tege/x86-timing.pdf)

I only saw evidence of data-dependent timing with respect to the div operation, but maybe I missed something.

Of course, I am not suggesting other operations are inherently immune to data- dependent timing leaks.

EDIT: I see there are also some notes on adc and sbb in some situations, i.e. chains of instructions that all light up the carry flag.

<comment><USER10> Don't worry about the instruction, worry about dest, src. If they:

\- Are in cache

\- Were touched by a previous instruction (regardless of cache)

\- Their cache line was touched by a previous instruction

\- Will be read/write (immediately) after that instruction

\- You're accessing data shared by multiple cores (lock prefix)

timing will vary

<comment><USER8> That's the whole point, though - the algorithm is very straightforward to implement _without_ data-dependent look-ups. So while any of those could affect execution time, none should do so in a way that leaks data.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Every major server ISA is, in this sense, "high level": the ISA is documented, but the microarchitecture isn't, and there are timing-relevant details known only to the manufacturers. Aciicmez famously demonstrated this with a timing attack on the branch prediction cache.

<comment><USER12> Any idea why the manufacturers haven't shown more interest in helping out crypto implementers? Surely timing attacks are a pretty prominent problem in microprocessor design circles by now.

<comment><USER13> Intel added AES, SHA-1 and SHA-256 instruction. They also added the PCLMULQDQ instruction to efficiently implement ECC. Via Padlock also have AES and SHA, and instructions for Montgomery multiplication (RSA speedup). Plenty of ARM SoC vendors offer crypto cores.

So the toolbox to implement e.g. TLS securely is pretty much there.

What isn't here is a way to implement new crypto primitives that would be timing attack and power analysis attack proof. But short of shipping a FPGA, I don't see how they could do it...

<comment><USER8> > They also added the PCLMULQDQ instruction to efficiently implement ECC.

Isn't this more typically used in GHASH implementations? Maybe it's applicable to both.

<comment><USER14> PCLMULQDQ is a godsend to both (GCM and binary elliptic curves), since both rely heavily on multiplication performance over F_{2^n}. The current fastest elliptic curve implementations are over binary fields using this instruction: [http://eprint.iacr.org/2013/131](http://eprint.iacr.org/2013/131).

<comment><USER8> Ah, interesting - so this applies in particular to elliptic curves over binary fields.

I may have missed this, but did they note how performance fared in the absence of hardware support?

Also, have binary curves (this or the NIST ones or any others) seen widespread deployment anywhere? I was under the impression that prime field curves were more widely used.

<comment><USER14> As far as I know they didn't try to make a good implementation without CLMUL. However, the older endomorphism-free curve2251 implementation [2, 3] is eye- opening:

\- the SSSE3 implementation is ~2.7 times slower than with CLMUL \- the generic (using mpfq, which should actually be pretty good) implementation is 5-6 times slower than with CLMUL

Binary curves used to be a lot more popular than they are now, before we all had fat multipliers in CPUs. The patent situation is worse for binary fields too, I think. That said, I'm pretty sure there are deployments somewhere using them; Dan Boneh's TLS survey [1] shows an overwhelming 96% of TLS clients using NIST's P-256, but the second most popular curve is NIST's B-233, at 3.6%. I would guess that this is due to hardware accelerators.

[1] [http://www.w2spconf.com/2014/papers/TLS.pdf](http://www.w2spconf.com/2014/papers/TLS.pdf)

[2] [http://bench.cr.yp.to/web- impl/amd64-titan0-crypto_dh.html](http://bench.cr.yp.to/web- impl/amd64-titan0-crypto_dh.html)

[3] [https://eprint.iacr.org/2011/170](https://eprint.iacr.org/2011/170)

<comment><USER8> Great info - thanks!

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> I think it's time to dig this: [http://yarchive.net/comp/linux/x86.html](http://yarchive.net/comp/linux/x86.html)

When Linus worked at Transmeta, doing a weird kind of processors and x86 was considered "a charming odity that works well".

</comment><comment><USER16> And this is perhaps a response to the 'heat leaks' story [1] about how tracking processor temperature over time you can get information out, or perhaps guess at what the processor is doing. (aka a 'side channel').

The basic observation is that in addition to the fact that CISC instructions do more than just one thing (they are essentially subroutine calls into microcode at one level of abstraction) out of order execution has added even more variability to _when_ they are executing. Making a goal of "constant time" programming (popular in crypto code and video timing loops) very difficult to achieve as the time may vary based on the data in play, instruction ordering, etc.

We're a long way from the time when you could right the number of cycles something would take on the right hand column of your assembly.

[1] [https://news.ycombinator.com/item?id=9250611](https://news.ycombinator.com/item?id=9250611)

</comment><comment><USER17> I wonder if introducing a sleep that is longer than the computation could conceivably take would work to solve (or at least make it a _lot_ harder to defeat) the actual problem. The failure case where the computation actually is slow enough to matter could be detected and thrown away.

This of course would require a fully async crypto lib..

<comment><USER18> That's not an effective technique, unfortunately. You still end up leaking timing information.

Lets say you add a small, random sleep after each operation – this still leaks information, as the delay can be averaged out over multiple runs. A fixed sleep after each operation is no use either, for obvious reasons.

One approach I've seen is to break time into discrete quanta – for example, you could guarantee that every operation will take an integer number of seconds to complete (i.e. an operation takes exactly 1 second, or exactly 2 seconds, or… scaled as required). There are still statistical techniques to extract timing information regardless, however!

The takeaway is the cryptography is really, really hard; system integrity is even harder.

<comment><USER19> The solution i've seen is:

        sleep(float(hash(request_content)) % n)

this assumes that the attacker cannot control any non-relevant part of request_content.

<comment><USER18> As far as I can tell, that would not be secure – wouldn't it end up being essentially cryptographically secure random timing noise? We already know that random jitter doesn't work, because it can be averaged out given enough samples.

I'm not a cryptography guy though, so I could well be wrong!

<comment><USER20> It cannot be averaged out, as there is no way to take multiple samples.

Look at it: for any specific input it always sleeps for a deterministic amount of time. Unlike random timing noise, which can be averaged away.

You take averages and all you know is the value of (actual time + some unknown value) very precisely. That doesn't help you.

(He is, however, missing that it should also have a random salt, generated once and stored.)

Of course, this is still breakable most of the time.

</comment></comment></comment></comment></comment><comment><USER21> I'm not sure what the takeaway from this is.

Don't implement crypto in software, only hardware? Does that cut out algorithm-writers who won't have FPGAs and fabrication available to them?...

<comment><USER22> You don't have to have FPGA or ASIC capabilities to develop a great new algorithm, do you? Do your research, prove it in software, get it into a product later... right?

<comment><USER21> True! My takeaway was needlessly bleak. Thanks :)

</comment></comment></comment><comment><USER23> I had this very same thought today, reading _Inside the Machine_ by Jon Stokes. Recommended. Amazing how abstract the programmer model can be from the real hardware.

</comment><comment><USER24> One of the links on the post, links to a stack overflow question, that has this code. What is the purpose of the do-while loop with the condition 0, how is that different to not having the loop at all?

#define BN_CONSTTIME_SWAP(ind) \

      do { \

        t = (a->d[ind] ^ b->d[ind]) & condition; \

        a->d[ind] ^= t; \

        b->d[ind] ^= t; \

      } while (0)

<comment><USER25> It's a common C macro idiom, that makes a multi-statment macro behave like a single statement. See [http://stackoverflow.com/questions/154136/do-while-and- if-el...](http://stackoverflow.com/questions/154136/do-while-and-if-else- statements-in-c-c-macros)

</comment></comment><comment><USER26> Forget the controversial opinion and drama, let's talk about something technical, how does the mov eax, ebx thing work? He said it will update eax to point to the same underlying register ebx points to. But then what happens when something like mov ebx, 9000h is executed? How does the CPU know that this will only apply to ebx, not eax?

<comment><USER25> The subsequent mov ebx, 9000h will cause ebx to "point to" a new underlying register, leaving the one that corresponds to eax intact.

<comment><USER26> So every time a new value is loaded into one of the "high level" registers, it's actually loaded into a new underlying register? So the underlying registers are basically immutable?

<comment><USER27> Yes, it's a allocation technique called "single static assignment".

</comment></comment></comment></comment><comment><USER28> If "constant time" programming isn't possible, could crypto code thwart side channel analysis by moving in the "other" direction - adding random amounts of spurious computation?

If I can't hide the work my code is doing by making it take the same amount of time (and use the same amount of power) no matter what I'm doing, seems like I could obscure it by adding a random amount of work - so that even the same "real" crypto workload would use varying amounts of power on subsequent runs.

Although I guess that would only be a partial solution at best. If an attacker could monitor many runs of the same "real" workload, some simple statistical analysis would still tell you some things.

<comment><USER3> > Although I guess that would only be a partial solution at best. If an > attacker could monitor many runs of the same "real" workload, some simple > statistical analysis would still tell you some things.

Yes, exactly. If you're doing a timing attack under non-ideal conditions, there are already plenty of sources of random delays -- e.g. network delays, delays introduced by the kernel scheduler, and so on. Adding additional random delay doesn't solve this fundamental problem.

</comment></comment><comment><USER29> "Inside the CPU, the results always appear as if the processor executed everything in-order, but outside the CPU, things happen in strange order."

I think the words 'outside' and 'inside' have been swaped

<comment><USER20> Nope.

Look at load/store ordering, for instance. To your thread (i.e. inside the CPU you're running on), things look normal. But outside your CPU, the order may be different than expected.

</comment></comment><comment><USER30> Yet another reason high-performance code will continue to be written in c/c++. Every abstraction layer from actual machine architecture severely convolutes the optimization process.

<comment><USER31> On x86 machines (which includes any standard desktop/laptop PC) C/C++ is compiled into x86 before it can be executed. Writing in C or C++ is actually _more_ abstracted than x86.

As a rule, hand-written x86 assembly will outperform C or C++, when both are very thoroughly optimised.</comment></comment>