2015-05-27

The reasons for the wars

Much of the public may still believe that the wars being fought in the Middle East are to protect the US from "terrorism". This is, of course, a sham. The rest of the public, however, appears to increasingly subscribe to the simplistic explanation that the wars are just to benefit a few "evil corporations".

The wars are about more than that. The wars do have a motivation in US national security (and even the national security of EU and other satellites of the US), it's just a deeper interpretation of "national security" than what the public would accept without extensive flattery and well, lying.

The wars are about US global economic dominance. They have nice side effects in terms of juicy bones that can be tossed to allies, but for the most part, they're about keeping the US economy running. Other than military hardware, there are few things the US still actually manufactures at this point, so inventing reasons to keep the military busy is a huge source of employment. Hypocrisy looms large in the US: huge chunks of the population are employed by the war industry more or less directly, at the same time as they espouse anti-government rhetoric and vote Republican.

Even more important than that, though, is keeping a firm military footprint in the Middle East to ensure that a large and substantial proportion of oil worldwide is sold in no other currency but US dollars. This ensures worldwide demand for USD, even in the face of such confidence-destroying events as the financial crisis, and even with the US hardly manufacturing anything these days outside of entertainment and intellectual property (which two thirds of the world do not respect).

The flip side of the coin is that allowing the petro-dollar to be abandoned would be a huge boost to China and Russia, which are not the world's most liberal regimes; and arguably, for better or worse, aren't ultimately whom you want to benefit.

It's not only about money either, but about control. When Russia is ever ready to invade and annex neighboring countries, it's crucially important that the US is in a position to tank the global oil market via its allies in the Middle East, making it costly for Russia to be expansionist. Being able to reduce Russia's revenues brings more sting to economic embargoes, and allows the West to oppose Russia without risking thermonuclear war.

Wars in the Middle East are of course not about humanitarianism, freedom, or democracy - at least, not for the people who live there. They are about realpolitik; about long-term strategic interests of the US, and of the West in general. This does ultimately benefit regular people in the US and the West; even to the extent of propping up our economies; protecting Europe's freedom from invasion by Russia; and the same freedom of Japan, South Korea, and Taiwan from China. But it is ugly and awful, and much of the public would not go along with it, if the whole thing was explained to it clearly.

And then, of course, there's Israel.

2015-05-21

You get what you pay for: Infographic

One of my biggest frustrations is that I can't get this point across to people. For some reason, people think that driven, principled, high quality individuals should be attracted to politics simply out of the goodness of their hearts!

The US problem is not Republicans vs. Democrats. It's that corporations buy your politicians because you begrudge paying them in any way proportional to good service. You get what you pay for, and the pittance you pay attracts few honest people, but primarily those who would abuse and sell power. It's not possible to fund a re-election campaign otherwise!



My previous posts about this:
  1. Study: Congress literally doesn’t care what you think (May 2015)
  2. Thoughts in favor of much better compensation for elected officials (July 2007)

2015-05-19

Acetaminophen may cause autism, ADHD in vulnerable children

I came across the following paper, which suggests convincing - though perhaps not yet fully conclusive - evidence that the incidence of autism might be greatly increased by acetaminophen (paracetamol) exposure in genetically susceptible children:

Evidence that Increased Acetaminophen use in Genetically Vulnerable Children Appears to be a Major Cause of the Epidemics of Autism, Attention Deficit with Hyperactivity, and Asthma

Cuba has some of the lowest rates of autism in the world. In comparison, vaccination rates are some of the world's highest; but, acetaminophen is not available without prescription. In fact: their medical system hardly ever uses acetaminophen, preferring a different antipyretic to treat fever.

In the US, on the other hand, there are physicians with the bizarre practice of prescribing acetaminophen prophylactically, every day for 5 days prior to a child's immunization.

The following is another paper suggesting that acetaminophen may be a culprit:

Did acetaminophen provoke the autism epidemic?

Article about a related study in TIME, February 2014:

Tylenol During Pregnancy Linked to Higher Risk of ADHD

2015-05-08

You get what you pay for.

In 2007, I posted:

You get what you pay for?
or
Thoughts in favor of much better compensation for elected officials

Now check out this study:

Study: Congress literally doesn’t care what you think

Specifically - check out this graphic:


Yeah.

That is the entire problem of US politics.

The smart people in your country are leveraging $5.8 billion over a decade to receive in return a thousand times more in favorable regulation and subsidies. It all ends up being paid to them at your expense. It's literally taken out of your paycheck.

The only reason this can happen is because you just don't want to pay your politicians well. They run a $10 trillion dollar country, and you're too stingy to pay them anything remotely resembling that responsibility.

So corporations pay instead. With your money. And it ends up costing you a thousand times more.

We can argue about getting money out of politics all day, but that's not really how this works. You need to get money into politics. If politicians are properly compensated by you, they will be harder to buy by others.

What they want is power. They wouldn't bend to corporations if they didn't happen to also need money.

2015-05-06

BusyBeaver key derivation function

June 27, 2015:

BusyBeaver is now available in your browser!



I present BusyBeaver, a password-based key derivation function (PBKDF) which I believe to be original and new. BusyBeaver attempts to improve on lessons of the past, which I would summarize thusly:
  • Recklessly foolish systems store passwords in plaintext. Anyone who peeks at database has everyone's passwords.
  • Naive systems try to protect passwords by storing their one-way hashes. It turns out it's cheap and easy to mount dictionary attacks.
  • Less naive systems store salted one-way hashes of passwords. It turns out low-iteration hashes are easy to brute-force.
  • PKCS#5 specifies PBKDF2, a salted one-way hash, repeated many times. Along comes Bitcoin, proving just how efficiently standard hashes can be brute-forced with GPUs, FPGAs, and ASICs.
  • Colin Percival creates scrypt, a PBKDF that attempts to increase the cost of brute-forcing by being memory-hungry. Along comes Litecoin, showing how GPU, FPGA, and ASIC optimizations are still quite feasible, and their improvements still measure in orders of magnitude.
BusyBeaver attempts to improve on this by taking advantage of what CPUs do well - serial execution of arbitrary code, 64-bit instructions, cache prefetch - in order to thwart optimizations that are made easier by the order of operations being static. BusyBeaver does not try to be as memory hungry as scrypt; top-end GPUs that might be used in brute-forcing now include so much memory per core as to make topping this expensive for legitimate users.

BusyBeaver operates as follows:
  1. Takes as input a salt and a password.
  2. Uses provided inputs to generate two 64 kB blocks of data using SHA-512 and HMAC-SHA512.
  3. Interprets the two blocks as byte code for a virtual machine where all inputs are valid as instructions and arguments. To avoid side channel attacks based on cache timing, all memory read/write offsets are controlled by the first block, which is generated from salt information only. Instructions perform calculations and changes on the second block, using operations that preserve entropy (jumps, additions, rotations, substitutions, XOR, and multiplication/modulo).
  4. The executed algorithm is unpredictable, but deterministically dependent on input.
  5. The algorithm is exceedingly unlikely to run into infinite loops, so much so that if it does, it's not a problem. Any infinite loops are local to very rare combinations of salt and password, and the attacker's cost of detecting them is greater than the maximum possible benefit.
  6. Processing stops when the requested number of operations have been executed.
  7. The final digest is produced as HMAC-SHA512 dependent on salt, password, and the final processed 64kB block.
BusyBeaver's C++ source code can be downloaded here:

BusyBeaver-20150703.zip (31 kB)

It is platform-agnostic, includes a test program, and comes with a permissive, free software license.

My implementation is parameterized by the number of operations to be executed. I find that a good value is on the order of 50,000 - enough to ensure that execution is not dominated by SHA-512, and nearly all bytes of the second 64 kB block have been replaced with different values.

The full KDF, parameterized with 50,000 operations, executes in about 6 ms on my machine as 64-bit code (of which 20% is SHA-512), and 18 ms as 32-bit code (of which 25% is SHA-512).



June 25, 2015:

We have verified that, at least on AMD R9 290X, BusyBeaver appears to resist attempts at GPU optimization. A colleague implemented and tested BusyBeaver with OpenCL, attempting to see if the insights that allow an efficient GPU implementation of scrypt, as used in LiteCoin mining, would also work on BusyBeaver. In the time allotted to this task, he was unable to implement a GPU version of BusyBeaver that would perform substantially better - or even significantly better - than what is achievable on CPU.

The crucial requirement to efficiently implement an algorithm on the GPU is to make calculations fit within the 32 kB of local memory available to each Compute Unit. In the scrypt case, normally more than 32 kB of memory would be required. However, scrypt has weaknesses (or features, if that's what you prefer) that allow the memory requirement to be reduced in exchange for computing more information on the fly. The parameters for scrypt, as used in LiteCoin, further require a low memory footprint, and the combination makes it possible to run the brunt of the algorithm within 32 kB.

With BusyBeaver, such optimizations are more difficult. Whereas scrypt only reads from the large memory buffer, BusyBeaver also writes to it. Whereas scrypt reads from the memory in large fixed chunks, BusyBeaver reads and writes in unpredictable sizes - often as small as one byte. In the time allotted to the task, my colleague has not been able to figure out how to meaningfully reduce the memory requirement. This means that each Compute Unit has to use global memory, which with this pattern of memory access is quite slow.

I expect that BusyBeaver would run orders of magnitude faster on a GPU with 128 kB, or at least 96 kB, of memory local to each Compute Unit. However, if we are to draw conclusions from the history of level 1 cache sizes for the CPU, we can suspect that there are tradeoffs involved with making this memory bigger. If similar pressures exist on the GPU that are keeping level 1 caches small on the CPU, major increases in local memory for general purpose GPUs may be unlikely. However, if GPUs were to introduce an intermediate category of memory, similar to level 2 cache on the CPU, that might also make them much more effective at running BusyBeaver.

I would love to see research into, and would welcome feedback from, any attempts to implement BusyBeaver efficiently on an FPGA. For the time being, I have confidence that BusyBeaver does favor the CPU more than alternative algorithms. We are therefore going ahead, and will be using it in the next version of Bitvise SSH Server.

July 2-3, 2015:

A parallel implementation, ParaBeaver, is now implemented separately in ParaBeaver.h/.cpp. It uses C++11 threading in order to run a number of concurrent threads processing BusyBeaver instances. ParaBeaver is useful on clients that can expect to have most cores idle, and can benefit from parallelization to gain security at no cost to the user.

The implementation of MulModOp64 now uses a right shift by 4 bits between multiplication and modulo in order to use a portion of multiplication result that preserves more entropy. The result of MulModOp64 is now used via rotBits in all instructions, to prevent the CPU from detecting it's not used and optimizing it away.

An additional parameter, swapBlockThreshold, is now supported to provide a tradeoff between side channel resistance and preventing an attacker from rearranging the order in which instructions are executed. BusyBeaver will now operate in side-channel-free mode the first 1/4 of the time (all memory offsets are exclusively salt-based), and will swap blocks the remainder of the time (memory offsets become also password based, and both blocks are read from and written to).

ParaBeaver supports swapBlockThreshold as well, and implements it sensibly for multithreaded execution.

2015-05-05

Honey badger ought to give a fuck

Sometimes people ask me, "Why do you care?" About some thing that they ostensibly don't care about.

Caring is important. Not caring is harmful.

I don't consider people less valuable if they are strangers. So many people will one day influence my life, who are now strangers to me. They all have value. Others, who will not be in my life, also have value. Their opinions do, as well.

I am ultimately connected to everyone. Therefore, I find it valuable to correct incorrectness when I can.

You could say I'm opposed to the church of "Honey Badger Doesn't Give a Fuck". Honey badger ought to give a fuck. People not giving a fuck - about the world, about people - is a disease. It's what is causing most of our trouble.

To not care about others is, ultimately, to not care about ourselves. Eventually, the not caring comes around, and bites us all in our collective ass.