Featured Post

Có một Biển Đông trên không gian mạng

Có một Biển Đông trên không gian mạng Thái Dương Mùa hè 2014, giữa lúc người Việt trong nước và hải ngoại đang sôi sục vì Trung Quốc đư...

Wednesday, September 30, 2015

HTTPS for blogspot.com - blogspot.com hỗ trợ HTTPS

As announced on the Google Online Security Blog, blogspot.com is now supporting HTTPS. Please update your bookmark, and from now on please visit this blog via HTTPS: https://vnhacker.blogspot.com.

If you have blogs on blogspot.com, you should enable HTTPS, and give your readers and yourself some privacy and security. Please leave a comment or email me at thaidn@gmail.com if you have any troubles after turning on HTTPS, I'm happy to help fix them. Unfortunately, blogs with custom domains are not supported now, but will be in the foreseeable future.

While HTTPS does not ensure 100% anonymity (not even close!), but it's still a very good start -- simply enabling HTTPS makes it much harder for anyone to uncover the identities of anonymous bloggers. We still have a long way to go, but we're working very hard on it, and we'll be back soon with more updates.

Please help spread the news!

--

Như đã thông báo trên blog Google Online Security, blogspot.com đã hỗ trợ HTTPS. Vui lòng cập nhật bookmark và từ rày về sau nên truy cập vào blog này qua ngõ https://vnhacker.blogspot.com.

Nếu bạn có blog trên blogspot.com, bạn cũng nên kích hoạt HTTPS để làm tăng thêm tính riêng tư và sự an toàn cho bạn đọc và chính bản thân của bạn. Vui lòng để lại còm hoặc email tôi ở địa chỉ thaidn@gmail.com, nếu bạn gặp bất kỳ trở ngại nào sau khi bật chức năng HTTPS, tôi sẽ rất vui sửa lỗi giúp bạn. Rất tiếc là các blog với tên miền tùy chọn chưa được hỗ trợ, nhưng sẽ được trong thời gian ngắn sắp tới.

Mặc dù HTTPS không thể đảm bảo ẩn danh 100%, nhưng mà nó cũng là bước khởi đầu rất tốt -- kể từ giờ trở đi, việc truy tìm danh tính của các blogger ẩn danh đã trở nên khó hơn rất nhiều. Chúng tôi còn rất nhiều việc phải làm, nhưng chúng tôi đang "cày" rất nghiêm túc và sẽ sớm trở lại với những cập nhật mới.

Làm ơn hãy loan tin giúp!

Tuesday, September 29, 2015

djb

Tôi đi hội thảo, vô tình ngồi kế bên djb. Ổng trông cũng... bình thường, cũng ngủ gục (giống tôi!) khi bài phát biểu chán quá =), nhưng mà ngồi kế một người đặc biệt như djb khiến tôi thấy có thêm cảm hứng học và làm ra cái mới.

Những ai làm quản trị hệ thống Linux hay UNIX có thể không nhớ djb là ai, nhưng mà nhắc qmail hay djbdns chắc nhiều người sẽ biết. Email và DNS là hai dịch vụ quan trọng nhất của Internet. Lúc bấy giờ, khoảng thập niên 80 và đầu 90 của thế kỷ trước, các máy chủ email và DNS thường chạy Sendmail và BIND9. Vấn đề là hai phần mềm này có cực kỳ nhiều lổ hổng bảo mật. djb viết qmail và djbdns để thay thế chúng và tuyên bố "gây sốc" là phần mềm của ông không có lỗi.

Dĩ nhiên là không ai tin, rất nhiều người lao vô tìm lỗi. djb phát hành phiên bản đầu tiên của qmail vào năm 1996, nhưng cho đến tận 10 năm sau đó không có ai phát hiện ra bất kỳ vấn đề gì. Năm 2005, Georgi Guninski, một huyền thoại khác của ngành bảo mật, phát hiện ra một lỗi tràn bộ đệm, nhưng djb cho rằng lỗi này rất khó khai thác trong các cấu hình mặc định của qmail, nên không trao thưởng. Dẫu vậy djb cũng công nhận đây là một lỗi và cho đến tận ngày nay đó là lổ hổng duy nhất được phát hiện. Đối với djbdns tình hình cũng tương tự. Chỉ có một lổ hổng duy nhất được phát hiện và trao thưởng vào năm 2009 (bật mí: người tìm thấy lổ hổng này từng làm ở nhóm của tôi ở Google).

Nếu như qmail và djbdns không có ai xài thì không nói làm gì, nhưng đây là hai phần mềm đóng vai trò cực kỳ quan trọng trong hạ tầng Internet. Yahoo! Mail và rất nhiều máy chủ email sử dụng qmail còn djbdns là phần mềm máy chủ DNS đứng thứ hai trên Internet. Chỉ cần qmail hay djbdns là đã đủ để đưa tên tuổi djb trở thành huyền thoại, nhưng ông không dừng lại ở đó. djb học toán ở Berkeley với Hendrik Lenstra (chữ L thứ hai trong thuật toán LLL lừng danh), rồi trở thành nhà nghiên cứu mật mã ứng dụng có ảnh hưởng rất lớn đến sự an toàn của Internet, nếu không muốn nói là lớn nhất. Lĩnh vực nghiên cứu chính của djb là mật mã tốc độ cao (high speed cryptography). Ổng muốn mã hóa toàn bộ Internet. Không những chế ra thuật toán, mà djb còn cung cấp miễn phí phần mềm triển khai các thuật toán này. Mỗi khi bạn sử dụng Chrome để xem Gmail, rất có thể bạn đang sử dụng những phát minh của djb.

--

Người ta hay nói, "Ba mươi tuổi mà chưa giàu thì phải xem lại mình", hay "Đừng tự hào vì mình Nghèo mà học Giỏi, hãy tự hỏi sao mình Giỏi mà vẫn Nghèo". Tôi không nghĩ làm giàu chân chính là sai, ngược lại, tôi thấy đó là một mục tiêu cao đẹp. Tôi ngưỡng mộ những người tạo ra của cải vật chất và đóng góp cho xã hội bằng cách tạo ra công ăn việc làm hay các hoạt động từ thiện. Xã hội cần phải có thêm nhiều người như thế. Chỉ là khi nhìn vào djb, tôi thấy một con đường khác để sống cuộc đời của mình, mà không phải quá bận tâm về chuyện làm giàu.

Monday, September 28, 2015

TetCon Saigon 2016

In the past few months many people have asked me if there will be TetCon Saigon 2016. My answer so far has been "probably." Today I'm excited to announce that I've finally decided to do it again. Time, venue, CFP, tickets, volunteer opportunities, etc. will be announced soon. Please watch https://tetcon.org and this blog for more updates.

There will be also training. I will teach crypto. Bruce and Thug4li3f might teach reversing. The classes are not free of charge, but we will have up to 100% scholarships for promising students and young researchers.

All proceeds from the conference and my class, after costs are covered, will go to charity and civil society organizations in Vietnam, e.g., Com Co Thit, Sach Hoa Nong Thon, etc.

Stay tuned!

Saturday, September 12, 2015

Đếm

Noi gương các nhà khoa học trẻ đếm số bài báo, tôi đề nghị chúng ta cũng đếm.

Từ rày về sau, giới thiệu lập trình sư, phải nói đầy đủ, "Đây là lập trình sư Trình Vẫn Cao, người đã viết 50 ngàn dòng code, nếu tính luôn comment là hơn 100 ngàn dòng, tất cả đều đã được công bố trên các máy chủ quốc tế của GitHub".

Lúc giới thiệu doanh nhân khởi nghiệp, phải nhấn mạnh, "CEO Phao Lờ Đờ, người đã có 407 ý tưởng khởi nghiệp, là chủ tịch Câu Lạc Bộ Những Nhà Khởi Nghiệp Trẻ có hơn 11 ngàn like trên Facebook. Với ý tưởng lập sàn giao dịch ý tưởng khởi nghiệp, Đờ và đồng sự đã thắng giải thưởng 100 triệu đồng của Quỹ Ý Tưởng Khởi Nghiệp Quốc Gia Việt Nam và với số tiền này, họ đang lên kế hoạch bành trướng ra toàn thế giới".

Khi giới thiệu kỹ sư bảo mật, phải ghi rõ, "Chuyên gia Hắc Đau Cơ, người đã tìm thấy 6 lổ, trong đó có 3 lổ khi tham dự các cuộc thi cướp cờ quốc tế được tổ chức ở Mỹ, Nga và Hàn Quốc; 2 lổ trong chính mã của anh ấy viết khi còn là nghiên cứu sinh tiến sĩ ở Ma Rốc. Năm 2014 Cơ phát hiện ra một tấn công từ chối dịch vụ gây ảnh hưởng đến 99.99% Internet. Anh ấy chỉ rằng chỉ cần tắt điện hoặc cắt cáp là Internet sẽ bị đứt. Cho đến nay các kỹ sư hàng đầu của Google, Facebook, Microsoft, v.v. vẫn chưa tìm được giải pháp".

Friday, September 11, 2015

Why not validate Curve25519 public keys could be harmful

Update: comments on Twitter.

Most users of Curve25519 believe that they don't have to validate public keys. I used to believe that too until I saw what could go wrong.

Recently I reviewed a protocol which could be simplified as follows
1. Alice and Bob perform the classic unauthenticated Diffie-Hellman dance. They obtain some shared keys at the end of this step.
2. Alice uses the shared keys to encrypt her data, and the resulting ciphertext is broadcast over radio (Bluetooth, WIFI, etc.) Since only Bob has the shared keys, nobody else could see the data.

This is more or less the same as SSL, except that the key exchange is unauthenticated. The designers have good reasons to believe that leaving the protocol unauthenticated poses a low risk only. They do their homework, and decide to use Curve25519, a state of the art Diffie-Hellman function. It turns out that this choice weakens the protocol.

If Mallory replaces Alice's and Bob's public keys with zero, which is a valid Curve25519 public key, he would be able to force the ECDH shared value to be zero, which is the encoding of the point at infinity, and thus get to dictate some publicly known values as the shared keys. It still requires an active man-in-the-middle attack to pull the trick, after which, however, not only Mallory can decode Alice's data, but everyone too! It is also impossible for Alice and Bob to detect the intrusion, as they still share the same keys, and can communicate with each other as normal.

If you haven't figured out what is going on yourself, the problem is that (0, 0) is a valid point on Curve25519, and has order of 2, i.e., (0, 0) + (0, 0) = the point at infinity. Curve25519 private keys are always even, thus the shared point would always be the point at infinity, whose x-coordinate is encoded as zero. If none of this makes any sense, I recommend buying a copy of An Introduction to Mathematical Cryptography.

Run this Sage script to see it yourself:

# the prime
P = 2^255 - 19
# the finite field over P
F = GF(P)
# Curve25519, see the paper
A = 486662
E = EllipticCurve(F, [0, A, 0, 1, 0])

# the point at infinity
INFINITY = (0, 1, 0)
# point (0, 0)
ZERO = E(0, 0)
# (0, 0) + (0, 0)
Q = ZERO + ZERO
# should output true
Q == INFINITY

OK, this sounds bad. How do I validate Curve25519 public keys? This is where the confusion begins. Let me first quote Curve25519 official answer:

How do I validate Curve25519 public keys?

Don't. The Curve25519 function was carefully designed to allow all 32-byte strings as Diffie-Hellman public keys [...]

There are some unusual non-Diffie-Hellman elliptic-curve protocols that need to ensure ``contributory'' behavior. In those protocols, you should reject the 32-byte strings that, in little-endian form, represent 0, 1, [...]

What is the contributory behavior? Should we care? It seems no, as long as we're using ECDH, but it recommends rejecting zero, which sounds like what we want to do to prevent the attack.



The answer is yes, you have to validate public keys if you are using a protocol that requires contributory behavior. This behavior, which sounds like a half-brother of the confused deputy, requires that none of the parties participating in the key exchange could dictate the shared value. But that is allowed in our example protocol! Exactly, now you see the root cause of the vulnerability. A better way to state the requirement is: you have to validate public keys if you are using a protocol that is vulnerable to key-dictating attacks.

You might think that I just made up a protocol to prove my point, but protocols requiring contributory behavior are not uncommon. For example, all versions of TLS <= 1.2 require this property, and as a result, are vulnerable to the triple handshake attack which uses a clever trick to dictate the shared value. I suspect that many homegrown protocols would be vulnerable too.

Whose fault is it? Many people, including me, consider Curve25519 the best practice when it comes to Diffie-Hellman. The problem is that, as a friend once said, in crypto there are also cases where the best practice is wrong, and the reasons are often subtle. This is one such case. I wouldn't blame the designers of Curve25519. Curve25519 was designed to do one job which is to compute the Diffie-Hellman function. It does its job well, but, like many powerful tools, it's, however, also a double-edged sword that could cause great harm when misused. Having said that, the attack would not work against NIST curves, but do not consider this as an endorsement of said curves -- they are inferior to Curve25519 in most aspects.

What is the solution?

Curve25519 suggests blacklisting the known bad public keys, but a better solution is to check the shared value and to raise exception if it is zero. You can also bind the exchanged public keys to the shared keys, i.e., instead of using H(abG) as the shared keys, you should use H(aG || bG || abG). If you exchange more than public keys -- TLS exchanges nonces, certs, and other info -- you should include them too. If you are implementing Curve25519 yourself, instead of encoding the point at infinity as zero, perhaps you should raise an exception. I cannot come up with any protocols which need to encode the point at infinity.

Thursday, September 10, 2015

Mùa hè đô la

Một bạn sinh viên đang học ở Việt Nam, sang Mỹ thực tập, 3 tháng, lãnh 600-700 chai, trừ thuế má ăn uống chơi bời đã đời, đem về nhà cỡ 300 chai.

Một thống kê gần đây cho thấy lương trung bình của kỹ sư CNTT ở Việt Nam là gần 19 chai/tháng, tức là thua lương của bạn kia khoảng 10-12 lần, nếu tính sau thuế thì khoảng 7-8 lần.

Như vậy thay vì đi làm toàn thời gian, các kỹ sư của chúng ta nên nghỉ, đi học, đợi hè đến đi thực tập ở Mỹ. Mỗi năm làm ba tháng thôi, đủ sống cả năm.