Binson is implemented in 9 languages

I just updated binson.org and noticed that I now know of 12 implementations of Binson. In 9 languages: Java, C, JavaScript, Go, Swift, Python, PHP, Erlang, and Rust.

That's a bunch. I believe there is no implementation in C#, otherwise all major languages seem to be included in the list. Not counting Kotlin, since binson-java could be used for that.

For you who don't know, Binson is an exceptionally simple, binary serialization format. It's like JSON, but binary. And actually significantly simpler. Full implementations of a Binson serializer/deserializer typically range between 100 and 1000 lines of code. The complete spec is just two pages long. I suppose that is why there are so many implementations. In general: KISS - keep it short and simple! The most important design principle.

The Cycle Gap

 

 

 

The figure above shows the progress of the speed of computer processors and human brains during the last 40 years. It is reasonable to say that computers have become 10,000 times faster during this period. And human brains have remained the same.

 

We can say that a processor cycle is 10,000 times cheaper then in 1980 while a "brain cycle" costs the same. Because of this, most software code today is not optimized to save processor cycles, but rather to save brain cycles of the developers. The development cost of software is typically much higher than the cost of running the software (energy, hardware). So, in general, we do not optimize code for computers anymore, but for the human authors of it.

With the increasing cycle gap, programming languages have evolved to save brain-cycles, at the expense of computer cycles. However, when it comes to embedded programming for resource-constrained devices, the C language is still the king of the hill. It was developed in the 1970s! Very successful, but hardly the most productive language to program in. Perhaps now it is finally time for a change. I have been reading up on Rust and how it works. It certainly sounds good. It is popular. And I really like the memory model.

Will it have a chance to compete with C for embedded? Well, well. Rust is in many ways technically superior. However, C has such robust support, so many compatible tools and a vast amount of available code that can be reused. C is clearly defined (has a spec) and has multiple implementations and is very stable. A clear advantage of C is that APIs and example code for embedded processors are typically written in C, not Rust or anything else.

If vendors of embedded processors would ship with example code and APIs in Rust, instead of C, then Rust would win! However, as the situation is now, I don't dare to predict the future. Being technically superior is not enough. However, I would love to see a more modern language that will really compete with C. Also in the embedded world.

Powerpinions Kill Decision Making

Let me coin a word: powerpinion. A powerpinion is an opinion of a powerful person on a subject he lacks necessary knowledge of. Often, a powerpinion is delivered through a Power Point presentation.

Powerpinions can completely kill the decision making skills of an organization. It can go so far, that a technical decision can be taken that is obviously wrong to just about any expert on the subject.

So, how to avoid this? Perhaps the following:

• If you are a person with power (formal or informal), please always listen very carefully to those with more knowledge than you on the subject matter.
• Read! Study! Get the knowledge you need before having opinions on something.
• Challenge powerpinions! Ask about the facts. What is that opinion based on? Do you have a reference to that fact? Did we ask the experts? Who is the expert on this in our organization? Can external experts be used?
• Written communication may help. Powerpinions are often delivered orally accompanied with hard-to-interpret Power Point slides that are soon forgotten. If opinions are recorded and can be referenced in the future, it likely makes people more hesitant to have opinions om subjects they lack knowledge in.
• Be careful with topics that seem simple at first, but are not. Cryptography is one example. Those who know the most realize how little they really know, but those who know a little, think they know it all.

Anything else? Comments are appreciated. There is probably relevant research in the area that would be interesting to consume.

Added 2023-03-06. Link to HIPPO effect text: t2informatik.de/en/smartpedia/hippo-effect/.

IoT: WAP all over again?

In 1999, the Wireless Application Protocol (WAP) was introduced. It gained an extreme amount of interest and hype the following years. We know what happened. It failed dramatically.

WAP is a set of protocols focused on the delivery of media to mobile phones. Essentially it is a whole new stack of protocols besides the already established HTTP/(TLS/)TCP/IP stack for content transfer and HTML to express the content. The protocols were motivated with the need for protocols more suited to less capable devices. It was believed that HTML+HTTP was too heavy for mobile phones.

And it was, sort of. Mobiles had bad Internet connectivity and small monochrome screens with a low resolution. However, as you know, this changed rather quickly. Now our mobile phones have megabits of bandwidth to the Internet, high-resolution color displays and very capable multi-core processors. It did not take long until it was realized that: yes, a mobile can handle the ordinary Internet protocols for content distribution: HTTP+HTML and email and so on.

I wonder:

    Is the IoT world in a WAP-phase today?

It is suggested today that the ordinary TCP/IP stack cannot be used for IoT devices because of the limitations they have in processing power, connectivity, energy consumption. Instead, special IoT protocols are suggested. In particular, CoAP/UDP is often suggested.

I don't know, but perhaps we are in a temporary phase (5-10 years) where some 8-bit IoT devices cannot speak the same language as the rest of the Internet. But will that situation last? The vast majority of the protocols that we associate with "Internet" uses TCP/IP. And nowadays and mostly TLS/TCP/IP is used to encrypt the Internet communication. This TLS/TCP/IP stack is used for the World Wide Web (HTTP), for SSH to control computers remotely, for REST to present cloud APIs, for email (IMAP, SMTP) and just about everything else on the Internet. Even Netflix uses TLS/TCP/IP to stream vast amounts of video data to its customers.

So, if we want our physical IoT devices to interact directly with the existing Internet, they should speak the same language. They should speak TLS/TCP/IP. Reusing only IP with, for example, CoAP/UDP/IP is typical for IoT devices today. However, I believe it may be only a matter of time before IoT devices also speak TLS/TCP/IP and thus can interact directly with existing Internet services without translation and with end-to-end security.

Notably, the IoT services: AWS IoT Core and Google IoT Core mandate the TLS/TCP/IP stack. So, to use those services end-to-end, a device must speak that stack. I wonder about Amazon's and Google's choice of not supporting CoAP/UDP/IP, for example. Instead of supporting such protocols for their cloud services, they advocate using a local bridge that translates, for example, CoAP/UDP/IP traffic to TLS/TCP/IP.

We will see. In 2030, we know the answer. No one knows. In the Internet world, the experts are often wrong. Me included. However, I think we should consider whether we can reuse the existing, well-established "big-Internet" protocols also for our smallest devices. Yes, there is some overhead, but it might be worth it. When we send IoT communication on the public Internet, we do have the same need for security. At least. Also, there are efforts to make the existing TLS/TCP/IP stack more efficient. Those efforts include TLS 1.3, TCP Fast Open, efficient TLS implementations, and 6LowPAN. Perhaps we should focus our energy on that instead of building up a separate, incompatible stack of protocols for IoT devices just like we did for mobile phones with WAP.

Delay attacks - the forgotten attack?

The unlock scenario

Together with colleges at ASSA ABLOY, I am working with a secure channel protocol called Salt Channel. It is open source and can be found on Github. One potential application is to control a lock (lock / unlock commands) from a credential in the proximity of the lock (RFID card, mobile phone, fob).

Typical secure channel implementations, like TLS, provide confidentiality and mutual authentication. Data integrity is also provided. They generality protect against attacks such as: replay attacks, various types of man-in-the-middle attacks and more. However, I know of no secure channel protocol that protects against delay attacks.

A delay attack is an attack where the attacker simply delays a packet in the communication. This is definitely in the scope of what an attacker is allowed to do in just about any threat model. Also, in practice, it can be easy to perform. Delaying a packet may not seem like a threat at first. Surely, it did not appear to us while developing Salt Channel v1, that a packet delay could be a security issue. Well, it can!

The figure about shows the scenario. Alice wants to unlock Lock with her phone through a radio communication channel (Bluetooth, Bluetooth Low Energy, NFC) to Lock. Mallory intercepts the communication and function as a man-in-the-middle. Alice establishes a secure channel with Lock. This is successful since Mallory simply forwards all messages between Alice and Lock. Then Alice sends the unlock message to Lock. Mallory recognizes this packet by packets size, packet ordering and so on (based on studying previous communication sessions). Mallory cannot read the contents of the package, nor modify it, however she delays it. Alice detects that she cannot open the door. Something seems to not work. She walks away. Once Alice is gone, Mallory, who is hiding near the door, sends the unlock packet. The Lock unlocks and Mallory can get in through the door without being detected.

Literature

I have not found literature focused on this issue. Perhaps I am just googling wrong, I have not studied this much. Any help is appreciated. I don't even know a name for this, so I invented "delay attack" since I could not find a term for it. Surely, this must be treated in public literature already.

Note, that this is not a replay attack. The packet is not replayed and a delay attack requires completely different counter-measures.

Note, this is not a timing attack. Even though timing is involved, timing attacks is a completely different thing and should therefore not be used for this type of attacks.

Existing delay attacks

There seem to exist practical delay attacks against car key systems.

Protection

Many application layer implementations likely do not consider packet delay attacks and their implications. It can be argued that there should be protection against delay attacks in the secure channel layer.

When Alice sends the unlock command she implicitly wants the door to open now. Not in 60 seconds. We can see this as an integrity protection of her intent to unlock now. Of course, this could be handled by the application layer. But why not put it in the secure channel layer? It sure seems like a general problem to deal with in a general way.

Perhaps another blog post will deal with countermeasures of delay attacks. We need some.

Appended

2020-02-24. These links are of interest. They use the term "delay attack".

https://tools.ietf.org/html/draft-mattsson-core-coap-actuators-06#section-2.2

https://tools.ietf.org/html/draft-liu-core-coap-delay-attacks-01

TestableThread - a Simple Way to Test Multi-Threaded Code

Multi-threaded code is hard to write and hard to test. For years, I have been missing simple tools for testing multi-threaded Java applications. Anyway, for certain types of test situations the TestableThread class can be used. See below and the TestableThread class at the java-cut repo.

The idea is simple. By introducing named "breakpoints" in code run by threads, the test management code can control the execution of a thread by telling it to go to a certain breakpoint. Breakpoints are added to normal code using statements like:

assert TestableThread.breakpoint("breakA");

By using an assert, the breakpoint code will not incur any performance penalty when the software is run in production (the default way to run Java software is without -ea, that is, without enabling assertions).

Given defined breakpoints, test code can let threads execute till they reach a given named breakpoint, for example, the code:

t1.goTo("breakA");

will enable the t1 thread to run until it reaches breakpoint "breakA". When the breakpoint is reached, the t1 thread will stop executing until it gets another goTo() request.


The implementation below is only 50 LOCs or something, but still have been shown to be useful. There are, of course, lots of improvements / additions to be made including conditional breakpoints.

Code:

public class TestableThread extends Thread {

    private final Object sync = new Object();
    private volatile String breakName;
    
    public TestableThread(Runnable r) {
        super(r);
    }
    
    /**
     * Run thread until it hits the named breakpoint or exits.
     */
    public void goTo(String breakName) {
        synchronized (sync) {
            this.breakName = breakName;
            sync.notifyAll();
        }
        
        if (getState() == Thread.State.NEW) {
            start();
        }
    }
    
    /**
     * Run thread, not stopping at any break points.
     */
    public void go() {
        goTo(null);
    }
    
    public static boolean breakpoint(String breakName) {
        if (breakName == null) {
            throw new IllegalArgumentException("breakName == null not allowed");
        }
        
        Thread thread = Thread.currentThread();
        if (thread instanceof TestableThread) {
            TestableThread tt = (TestableThread) thread;
            synchronized (tt.sync) {
                while (tt.breakName != null && tt.breakName.equals(breakName)) {
                    try {
                        tt.sync.wait();
                    } catch (InterruptedException e) {
                        throw new Error("not expected: " + e);
                    }
                }
            }
        }
        
        return true;
    }

 }

The Unsolvable Rubik's Cube?

Introduction

A very puzzling thought has been on my mind for a while now: is it possible to create a mechanical puzzle, something like the Rubik's Cube, that is unsolvable in general, but still demonstrably solvable if one knows the scrambling moves.

Such a puzzle would be truly mind-boggling and incredible frustrating for puzzle-solvers. Imaging a puzzle that starts from the solved state, just like a Rubik’s cube with all sides completed. Then, a long enough sequence of random moves (a scrambling sequence) would make it impossible to go back to the solved state if the scrambling sequence is not known. If the scrambling sequence is known, it is however trivial to reach the solved state by simply applying the inverse of each move in the scrambling sequence in reverse order.

The definition of unsolvable

By impossible to solve or unsolvable, we mean that it is infeasible for a human to reach the solved state given a scrambled puzzle. To be concrete: there should be no general algorithm that solves the puzzle in less than 100 million moves. This roughly corresponds to one move every second for three years. Of course, one could always be lucky and find the solution faster, but on average, there should be no way to solve the puzzle in less than 100 million moves. And this is by my definition "infeasible" for a human to do.

Notation and puzzle properties

Let's go ahead and define this problem more rigorously.

Consider a mechanical puzzle with a finite distinct number of states. From a particular puzzle state, S, another state can be reached by making a move. A move, m, is a mathematical function from one puzzle state to the next.

    Si = mi(S_i-1)

OK, that looks ugly. MathML looks much better:

  ${\displaystyle S_i=m_i\left(S_{i-1}\right) }$

but it is slow to edit and does not work on all browsers (mobile phone browsers in particular). Let's go on using the ugly style.

Every move, m, has a corresponding inverse move, m'. So, for every move, m, and every state, S, there is an inverse move, m', such that:

  S = m'(m(S))

When dealing with long move sequences, the function notation with all the resulting parenthesis is too annoying, instead we will use the following notation:

  S3 = S0 | m1 m2 m3

to mean that when moves m1, m2, and m3 are applied to state S0, the resulting state is S3. So, with the new notation, we have:

  Si = Si-1 | mi

and

  S = S | m m'

Each puzzle state has a corresponding finite set of possible next moves. In the case of the Rubik's Cube, each state has 12 possible next moves (only 90 degree moves are considered, "quarter-turn metrics"). Often they are denoted: F, Fi, B, Bi, U, Ui, D, Di, L, Li, R, Ri.

The puzzle has one particular state called the solved state. Solving the puzzle is equivalent to finding a move sequence that transforms the current state to the solved state.

A scrambling of the puzzle is a random sequence of moves starting from the solved state. At each state, the next move is chosen randomly. Each possible next-move has the same probability of being chosen. A random scrambling of size n, is a random scrambling with n moves.

Now we are ready to summarize the properties of our puzzle. Lets call it an F-puzzle to distinguish it from other puzzles. An F-puzzle is a puzzle with the following properties:

• The puzzle has a finite number of states.
• One puzzle state is called the solved state.
• Each puzzle state has a set of next possible moves. The set is finite and has a size of at least two.
• For any state, S, and any move, m, there is an inverse move, m', such that:
  S = S | m m'.
• A scrambling is a random sequence of moves starting from the solved state. The state after a scramble of size N is:
  S_scrambled = S_solved | m1 m2 m3 ... mN.
• A scrambling is trivial to unscramble given that the scramble sequence is known:
  S_solved = S_solved | m1 m2 m3 ... mN mN' m(N-1)' ... m3' m2' m1'

Hopefully, that is precise enough. Tell me if the F-puzzle definition is not clear.

The Rubik’s Cube is one example of an F-puzzle. However, it is solvable. In particular, any scrambling of the Rubik’s Cube can be solved in 20 moves in half-turn metrics and 26 moves in quarter-turn metrics. See www.cube20.org.

The problem

So, now we can state the problem.

1. Can we create a mathematical unsolvable F-puzzle?

2. Can we create a mechanical unsolvable F-puzzle?

3. Can we create a practical mechanical unsolvable F-puzzle that can be mass-produced with a unit cost below 100 Euro?

To be concrete, we would like a mechanical puzzle that cannot be solved in 100 million moves after a scrambling of size 100 or less (20 or less would be nice). By "practical", we mean a puzzle that can be scrambled or unscrambled within one minute by most humans without training or tools. We also want a solution that is not a "mechanical computer"; it should be more of a Rubik's cube than a mechanical computer where symbols are used. For example, we don't want something like a code lock where digits are used to set a code.

That's the problem. Let's discuss potential solutions some other time.