Home » 2016 » August (Page 2)

SWEET32:攻 Blowfish 與 3DES

最新的攻擊算是實戰類的攻擊,理論基礎以前都已經知道了,只是沒有人實際「完成」。算是近期少數直接對演算法的攻擊,而這些演算法剛好還是被用在 TLSOpenVPN 上,所以嚴重性比較高:「SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN」。

攻擊的條件是 block cipher 的 block size,而非 key length,所以就算是 256 bits 的 Blowfish 也一樣也受到影響。

這次順利打下 Blowfish3DES。這兩個 cipher 的 block size 都是 64 bits,所以對於 birthday attack 來說只要 232 就可以搞定:

This problem is well-known by cryptographers, who always require keys to be changed well before 2n/2 blocks. However it is often minimized by practitioners because the attacks require known plaintext, and reveal only little information. Indeed, standard bodies only recommend to change the key just before 2n/2 blocks, and many implementations don't enforce any limit on the use of a key.

在 OpenVPN 打 Blowfish 的部份 (Blowfish 是 OpenVPN 預設的 cipher):

In our demo, it took 18.6 hours and 705 GB, and we successfully recovered the 16-byte authentication token.

以及 HTTPS 打 3DES 的部份 (為了相容性問題):

Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.

都是有可能的等級。也該來拔掉對 IE8 的支援了... orz


Nuclear Fallout Shelter 照字面翻是核放射塵碉堡,意思上算是可以對抗輻射塵的防空洞,用 Google Translate 翻出來是「核輻射避難所」,感覺也頗貼切的啦...

而 C14 project 則是 Online.net 在巴黎的核輻射避難所建立 data center 的玩意:「C14 story - Part 1 Meet Our Nuclear Fallout Shelter

在地下 26 公尺,如果一層樓三米的話,大約是已經是地下八樓到九樓的位置了:

Starting in October 2016, you will be able to store all your critical C14 data in our fallout shelter, located 26 meters underground in Paris, France.

整個計畫在 2012 年從法國政府買下來,然後開始重建:

In 2011, the French state, owner of the building, decided to move the Ponts et Chaussées' central laboratory in the Parisian suburb and started to dismantle the building.

The Ponts et Chaussées' central laboratory buildings were revamped and divided in multiple bundles to be sold and transformed in multi-unit housing. The main building and the shelter were sold separately via a public invitation to tender. Online landed the deal in September 2012 with the project to build a Datacenter. The project’s codename is DC4.



無縫更換 symbolic link 所指的目錄或檔案

這邊如果把 atomatically 翻成原子性好像怪怪的,就照意思來翻好了。

這是一篇 2005 年的文章,講如何更換 symbolic link 內容,而且確保 symbolic link 不會短時間不見:「How to change symlinks atomically」。

作者拿了 strace 解釋 ln -snf 的例子,來說明這個方法沒辦法做到無縫:

$ strace ln -snf new current 2>&1 | grep link
unlink("current")         = 0
symlink("new", "current") = 0

unlink()symlink() 中間的 race condition 如果有人存取這個 symbolic link 就會失敗。作者提了這樣的方法來解決:

$ ln -s new current_tmp && mv -Tf current_tmp current

在「How does one atomically change a symlink to a directory in busybox?」這邊雖然提問的是 BusyBox,但道理相同,提到了怎麼做以及為什麼 (不要看綠色勾勾那個,看分數比較高的那個):

This can indeed be done atomically with rename(2), by first creating the new symlink under a temporary name and then cleanly overwriting the old symlink in one go.

DocumentRoot 是 symbolic link 時,這點變得很重要。這個方法才能避免切換目錄的過程中間不會有空檔,導致使用者收到 404...

另外通常會配合 mod_realdoc 一起用,避免程式用到 DocumentRoot 的路徑而導致前面指到的東西跟後面指到的東西不同。

NIST 新的密碼規範

NIST 所提出來的規範 (Special Publication 800-63-3: Digital Authentication Guidelines),雖然還在 Draft 階段,但可以看出目前密碼規範的趨勢跟以前的不同:「NIST’s new password rules – what you need to know」。

整份規範可以在 GitHub 上讀到,不過 markdown 好像沒處理好,直接在 GitHub 上看到的有點亂,不過還算看得懂就是了...

在 NIST 網站上有 html 版本「Digital Authentication Guideline: Public Preview」可以讀,應該會好一些。

整份 guideline 很長,密碼的部份主要是在「DRAFT NIST Special Publication 800-63B Digital Authentication Guideline」這份裡面關於「Memorized Secrets」的部份。


  • 有「安全問題」反而會讓系統安全變弱。
  • 要求使用者有大小寫、特殊符號這種讓使用者更難記密碼的限制,反而會讓使用者選出更差的密碼。讓使用者自由選擇密碼,同時用黑名單機制把常見的密碼擋下來會是比較好的選擇。
  • 定期換密碼反而會讓使用者選擇更差的密碼 (因為要花力氣記,所以會選擇簡單的密碼),不如讓使用者選一個強一點的密碼一直用。同時要合理設計限制登入錯誤的機制。
  • 絕對不可以存明碼。

下面開始 copy & paste 然後給簡單的註釋...

首先是對最低長度的定義,至少要八碼。而對最大長度的限制是「至少你要讓使用者可以輸入 64 碼」:

Verifiers SHALL require subscriber-chosen memorized secrets to be at least 8 characters in length. Verifiers SHALL permit user-chosen memorized secrets to be at least 64 characters in length.

密碼不應該限制特殊字元,只要可以印出來的 ASCII 與空白都應該被允許,而 Unicode 也應該要被允許:

All printing ASCII [RFC 20] characters as well as the space character SHALL be acceptable in memorized secrets; Unicode [ISO/ISC 10646:2014] characters SHOULD be accepted as well.


Verifiers MAY remove space characters prior to verification; all other characters SHALL be considered significant.

要注意的是,為了強度,每一個 Unicode 應該只算一個有效字元:

For purposes of the above length requirements, each Unicode code point SHALL be counted as a single character.


Memorized secrets that are randomly chosen by the CSP (e.g., at enrollment) or by the verifier (e.g., when a user requests a new PIN) SHALL be at least 6 characters in length and SHALL be generated using an approved random number generator.


Memorized secret verifiers SHALL NOT permit the subscriber to store a “hint” that is accessible to an unauthenticated claimant. Verifiers also SHALL NOT prompt subscribers to use specific types of information (e.g., “What was the name of your first pet?”) when choosing memorized secrets.

然後針對已知的弱密碼 (像是字典單字,以及之前被洩漏出來的密碼) 都應該擋下來:

When processing requests to establish and change memorized secrets, verifiers SHOULD compare the prospective secrets against a dictionary of known commonly-used and/or compromised values. This list SHOULD include passwords from previous breach corpuses, as well as dictionary words and specific words (such as the name of the service itself) that users are likely to choose. If the chosen secret is found in the dictionary, the subscriber SHOULD be required to choose a different value. The subscriber SHOULD be advised that they need to select a different secret because their previous choice was commonly used.

另外不應該要求使用者要特殊字元或是大小寫這種限制,而且也不應該要求使用者定期換密碼 (除非確認被破了):

Verifiers SHOULD NOT impose other composition rules (mixtures of different character types, for example) on memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically) unless there is evidence of compromise of the authenticator or a subscriber requests a change.

另外禁止用明碼存密碼,必須用 PBKDF2 這類可以防禦快速離線計算的演算法:

Verifiers SHALL store memorized secrets in a form that is resistant to offline attacks. Secrets SHALL be hashed with a salt value using an approved hash function such as PBKDF2 as described in [SP800-132]. The salt value SHALL be a 32 bit (or longer) random value generated by an approved random number generator and is stored along with the hash result. At least 10,000 iterations of the hash function SHOULD be performed. A keyed hash function (e.g., HMAC), with the key stored separately from the hashed authenticators (e.g., in a hardware security module) SHOULD be used to further resist dictionary attacks against the stored hashed authenticators.

DigitalOcean 開始加收 Snapshot 費用

收到 DigitalOcean 的信件通知,snapshot 會開始收費:

Starting October 1, 2016, we will begin charging for snapshot storage at $0.05 per gigabyte per month. This will first be reflected in the invoice posted to your account on November 1, 2016. Like other features, snapshot storage uses hourly pricing, and size is calculated from a compressed version of the snapshot—not the total disk space allocated to the Droplet.


Facebook 開源的 fastText

準確度維持在同一個水準上,但是速度卻快了 n 個數量級的 text classification 工具:「FAIR open-sources fastText」。

可以看到 fastText 的執行速度跟其他方法的差距:

Our experiments show that fastText is often on par with deep learning classifiers in terms of accuracy, and many orders of magnitude faster for training and evaluation.

除了 open source 外,也發表了論文:「Enriching Word Vectors with Subword Information」,看 abstract 的時候發現提到了 Skip-gram:

In this paper, we propose a new approach based on the skip-gram model, where each word is represented as a bag of character n-grams.

結果找資料發現自己以前寫過「Skip-gram」這篇 XDDD


在「Page dewarping」這篇看到講文件掃描的技術,以及 open source 的程式,對比之前提到的「Dropbox 的文件掃描功能」與「Dropbox 的 Document Detecting」的時間點,有種淡淡的惡意 XD


A while back, I wrote a script to create PDFs from photos of hand-written text. It was nothing special – just adaptive thresholding and combining multiple images into a PDF – but it came in handy whenever a student emailed me their homework as a pile of JPEGs. After I demoed the program to my fiancée, she ended up asking me to run it from time to time on photos of archival documents for her linguistics research. This summer, she came back from the library with a number of images where the text was significantly warped due to curled pages.

So I decided to write a program that automatically turns pictures like the one on the left below to the one on the right:

程式都可以在 GitHub 上翻到:「Text page dewarping using a "cubic sheet" model」。跟 Dropbox 互別苗頭的感覺 XDDD