Archive for the ‘crypto’ Category

Tor compromised

Wednesday, July 20th, 2016

It has long been known that much of the resources for Tor are provided by US spy agencies. Which is not necessarily a bad thing, since they might want a means for communicating that no one can spy on.

However, Lucky Green, a key figure in the privacy community, has issued a warrant canary – what you issue when you are forbidden to tell people you have had a warrant served on you.

The canary fails to tell us that a US spy agency is inside his servers in a way that tells us that a US spy agency now is inside his servers and a many other Tor servers.

In a warrant canary, you say what you are forbidden to say by failing to say things that you would otherwise be expected to say.

This inclines me to Moldbug’s solution, assuming his interpreter and compiler can be sufficiently small and self contained that one can make sure that everyone runs the same one. But if the interpreter and compiler exceed sixteen thousand lines, then defending them against this sort of attack becomes difficult.

Against urbit

Tuesday, April 5th, 2016

The world is moving to cloud computing – which means that the world is moving to giant megacorps that are excessively cozy with the government owning all your data.

Which, as general David Petraeus discovered, can be really bad for you. Google tipped off his enemies, not by reading his email, though they did read his email, but by tracking where he was when he logged in to gmail. Which is why Hillary likes to keep her email server’s database on a thumb drive that she personally controls. Supposedly this is bad for national security, but I am pretty sure it is mighty good for Hillary’s security.

Urbit is intended to fix this:

Your urbit is a personal server: a persistent virtual computer in the cloud that you own, trust, and control.

Unfortunately urbit is also a language, a rather weird language, and a language that is interpreted rather than compiled.

A compiler can compile itself, and usually does. An interpreter cannot interpret itself.

Urbit, as a language, is kind of like Haskell as a language.   Except that Haskell has a compiler, which is a huge advantage.

Let us suppose you want to multiply two times three in Haskell:

Well if you multiply two by three in C++, the compiler generates code that loads the number two into a register, loads the the number three into another register, multiplies the registers together, then stores the result where you tell it to store it.

If you multiply two by three in Haskell, the interpreter first creates a function to multiply any number by two, then applies that function to the number three, and it does not store the result. Which means if you have any non trivial program, it is pretty hard to figure out what the program is actually doing and how much time and memory space the task is going to take. Except that you can be pretty sure it is going to take more time and more memory space than doing it in C++.

Does anyone actually use anything written in Haskell?  All alleged successful uses of Haskell are in-house usages – the man who uses the program is the man who wrote the program.   We don’t see someone writing something in Haskell, and then large numbers of other people using his software.  If you google any standard language, you get lots of hits of people wrestling with vast amounts of data used by vast numbers of people.  If you google functional languages, you get academics playing interesting and clever games for the entertainment of other academics.

I rather suspect that no one except Yarvin is likely to be able to write any large efficient program in Urbit.

In order for Urbit “your personal server on the cloud” to be useful, your personal server needs to provide tools that are the functional equivalent of blogging, tweeting, reddit, facebook, Github, email, the pirate bay, the silk road, ebay, and such.  Tools whereby you can use your personal server to securely interact with other people.

Not seeing specs for such tools.   Such tools seem like a lot of work.

The huge advantage of a language such as Urbit is that the cloud is inherently massively parallel, and Urbit is designed to be inherently adapted to massive parallelism.  Your personal server on the cloud can scale – enormously.  Which is more of an advantage if you are a giant corporation.  And even so, giant corporations do not use such languages, because they are hard.

Something like Urbit is the right way to do things in a massively networked environment.  But it is an enormous and difficult task.  Writing a compiler would not be such a big job compared to all the other jobs that have to be done to make Urbit useful.

Urbit is a bright idea.  It is a correct idea.  But it is a really big job.

 

Bitcoin crisis

Friday, January 15th, 2016

Back in the beginning, I argued bitcoin would not scale.

The counter argument was that we could muddle our way through somehow with ad hoc solutions, which could be sort of true, in principle.

The scaling problems started to bite in 2013.  They are now biting really hard.

The scaling problems are now well and truly here.  Downloading the blockchain is slow and expensive.  Doing transactions is slow, unpredictable, expensive, and unpredictably expensive.

Any solutions hurt, are partial, incomplete, unsatisfactory, and will  disadvantage some people financially.   Civil war in the bitcoin community has ensued over which people it is to be.

That outcomes are determined by weight of computing power (the miners) rather than weight of bitcoins owned has led to problems.  The miners don’t face the same incentives as the people trying to do bitcoin based businesses.

Bitcoin has grown to about as large as it can get.  It is doing about as many transactions as it can do, arguably rather more transactions that it is really suited for doing.  Any fixes are at best small tune ups to get a little bit more performance out of the system, are at worst just burden shifting and burden hiding – hence the civil war. I have been trying to design a coin that could scale, by having a dispersed blockchain, where no one entity has to keep all transactions.   You keep your own transactions, and summary information about entities you transact with, and summary aggregate information about all transactions, and the chain of hashes that links the ownership of your money and your transactions into the global hash, which chain would only grow as log of the total number of transaction, rather than grow with the total number of transactions. This means that parts of the blockchain will get lost temporarily or permanently, and the problem is to create a method for dealing with such losses that does not give anyone incentive to cause such losses, apart from the general deflation that such losses cause.  Have been trying to design this for some time.  Not making much progress these days.

Another solution, compatible with existing bitcoin is to have account based money built on top of bitcoin, bitcoin backed banks, analogous to gold backed banks.  People are talking about this solution, but not actually implementing it, even though it seems a good deal easier than the solution that I proposed.

Tim Cook “I am proud to be gay” spys on Mac users

Saturday, November 8th, 2014

In the recent release of the Mac operating system:

If you set up an email that does not belong to Apple, the OS phones your email domain home to Apple to help them dox you.

No matter who you use a search provider, the browser reports your search strings to Apple

Silk Road 2.0 goes down

Saturday, November 8th, 2014

“This hidden site has been seized”

We are going to need a heavily decentralized solution, so that if a relatively small number of nodes get shut down or taken over by law enforcement, the network continues to function correctly, and, because no single node is central, no single node has traffic patterns that make it stand out.

The Tor hidden site system will always fail if a hidden site generates too much traffic for too long. We need a non Tor solution for publishing and curating reputations and performing transactions.

Bitcoin failure

Sunday, June 15th, 2014

For bitcoin to work politically, authority over the currency needs to be distributed over a large group of peers. If power is concentrated at a single point, the state can dominate that point, whoever controls that point can steal other people’s currency and do a variety of bad things.

Bitcoin was designed so that “voting” depended on computing power and network connection. Initially, almost everyone who had a client was a miner, there were a huge number of miners, everyone who used bitcoin had roughly equal influence because they contributed roughly equal computing power to the block chain.

Today, bitcoin is controlled by by a single miner., which was a predictable consequence of bitcoin’s scaling problems.

What we need is a crypto currency which is controlled by the top one hundred or so owners of the currency that are well connected to the net and have adequate computing power, with influence over the currency proportional to the amount of currency that they own, rather than the number of cycles that they burn.

In principle it should be possible to do this using bilinear maps, but the details are a bit tricky, because we have to make sure that manageable number of votes reflects an infinitely divisible currency whose ownership changes continually. So the shares (private and public keys in groups with a bilinear map) have to be reissued frequently, while ownership of the infinitely divisible currency is given value by the fact that if you own a lot of it, you get shares proportional to the amount you own. Since shareholders are people who own a lot of currency, they have an incentive to not misbehave, to continue to reissue shares according to currency ownership and validate transactions according to the rules, since to do otherwise would destroy the value of the currency that they own.

The number of shares remains manageably small, however many people use the currency and however many transactions take place. The shares underlie the value of the currency – and absolutely nothing underlies the value of the shares. Of course we still have other scaling problems, to which I have not figured out a solution except in alarmingly vague outline.

Lessons from the silk road.

Wednesday, October 16th, 2013

As I said earlier, without providing evidence or explanation, the big flaw was that the server kept the messages in the clear.  A recent news report has confirmed this from official sources: (more…)

The underground economy continues

Saturday, October 5th, 2013

I, and others, have been assuming that the takedown of Silk Road represents competent action by the NSA.

Outside In, however, points out the interesting coincidence that the takedown of Silk Road follows, rather than precedes, the appearance of competition to Silk Road.

Atlantis, however, appears to have skedaddled with its user’s money, thus this looks like a successful shutdown of the online black market, hence likely to be primarily state action.

So, contrary to the headline, the underground economy does not continue.

Technological failure of the silk road system

Friday, October 4th, 2013

Silk Road servers stored all messages in the clear forever.

The government placed malware on Tor exit nodes, located the Silk Road servers, raided servers, game over.

Private messages should have been end to end encrypted, existing in the clear only on the computers of the sender and recipient, and should have been deniable, except for messages containing money, where the sender needed to be able to prove that the recipient account had received a message with a particular hash, and thus able to prove that the recipient account received a message with particular content including payment. (more…)

Cryptography standards

Friday, October 4th, 2013

If everyone was to do their own thing in cryptography, that would be very bad.

But committees are less intelligent than their individual members and are prone to evil and madness.  IEEE 802.11 was stupid. If NIST was not stupid, it was because evil was calling the shots behind the scenes, overruling the stupid.

Linux was a success because Linus is unelected president of linux for life.

Let us follow Jon Callas as unelected president for life of symmetric cryptography, Daniel Bernstein as God King of asymmetric cryptography.