Home » Posts tagged "hash"

兩個 gperf...

翻資料的時候覺得怎麼跟印象中的不太一樣,多花些時間翻了一下,發現原來有兩個東西同名...

一個是 GNUgperf,給定字串集合,產生 C 或 C++ 的 perfect hash function (i.e. no collision):

GNU gperf is a perfect hash function generator. For a given list of strings, it produces a hash function and hash table, in form of C or C++ code, for looking up a value depending on the input string. The hash function is perfect, which means that the hash table has no collisions, and the hash table lookup needs a single string comparison only.

另外一個是 Google 弄出來的 gperftoolsmalloc() 的替代品以及效能分析工具:

gperftools is a collection of a high-performance multi-threaded malloc() implementation, plus some pretty nifty performance analysis tools.

Etsy 介紹的 Cache Smearing

Etsy 的 engineering blog 上提到了他們怎麼設計 cache 機制:「How Etsy caches: hashing, Ketama, and cache smearing」。

使用 consistent hash 已經是基本款了,文章裡花了一些篇幅介紹為什麼要用 consistent hash。

後半段則是有了 consistent hash 後會遇到的問題,也就是講 hot key 怎麼處理:有些資料非常熱 (常常被存取),就算用 consistent hash 也還是有可能搞爆單一機器。

他們做了幾件事情,第一件事情是設計 cache smearing 機制,把單一資料加上 random key,使得不同的 key 會打散到不同的機器上:

Let’s take an example of a hot key popular_user_data. This key is read often (since the user is popular) and is hashed to pool member 3. Cache smearing appends a random number in a small range (say, [0, 8)) to the key before each read or write. For instance, successive reads might look up popular_user_data3, popular_user_data1, and popular_user_data6. Because the keys are different, they will be hashed to different hosts. One or more may still be on pool member 3, but not all of them will be, sharing the load among the pool.

第二件事情則是監控哪些 key 比較熱門:

We’ve seen this problem many times over the years, using mctop, memkeys, and our distributed tracing tools to track down hot keys.

第三件事情是維護 hot key 的清單 (不是每個 key 都會上 cache smearing):

We manually add cache smearing to only our hottest keys, leaving keys that are less read-heavy efficiently stored on a single host.

是個當規模大到單一 hot key 會讓單台伺服器撐不住時的 workaround...

下一代的 Tor Hidden Service

Tor 公佈了下一代的 Hidden Service (Onion Service):「Tor's Fall Harvest: the Next Generation of Onion Services」。

三年前 Facebook 自己暴力算出 facebookcorewwwi.onion 這個很特別的名字 (參考「Facebook 證明 Tor 的 Hidden Service 不安全」),這陣子連紐約時報也能暴力算出 nytimes3xbfgragh.onion 這個好名字 (參考「紐約時報網站上 Tor 的 Hidden Service (i.e. Tor Onion Service)」,這讓只有 16 chars 的 hostname 的 hashed-space 不夠大的問題愈來愈明顯 (只有 80 bits 的空間)。

如果你也想要找出一個有趣的 hostname 的話,可以用 lachesis/scallion 這樣的工具,這程式用 CPU 產生出 RSA key 後,再用 GPU 算 SHA-1

The inital RSA key generation is done the CPU. An ivybridge i7 can generate 51 keys per second using a single core. Each key can provide 1 gigahash worth of exponents to mine and a decent CPU can keep up with several GPUs as it is currently implemented.

也因為如此,Facebook 與紐約時報在上線時並不是直接在 Hidden Service 上裸奔,而是上了 HTTPS 作為 workaround,以避免資料外洩。

但這畢竟是 workaround,Tor 的人還是希望協定本身就可以提供一個夠安全的架構,而花了四年多發展出下一代的 Hidden Service,也就是這次提到的成果了。

最大的改變就是 hostname 變長很多了,從本來的 16 chars 變成 56 chars:

And finally from the casuals user's PoV, the only thing that changes is that new onions are bigger, tastier and they now look like this: 7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion.

hostname 變長主要是因為把整個 256 bits public key 放進去,可以從 spec 看到:

6. Encoding onion addresses [ONIONADDRESS]

   The onion address of a hidden service includes its identity public key, a
   version field and a basic checksum. All this information is then base32
   encoded as shown below:

     onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion"
     CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]

     where:
       - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service.
       - VERSION is an one byte version field (default value '\x03')
       - ".onion checksum" is a constant string
       - CHECKSUM is truncated to two bytes before inserting it in onion_address

  Here are a few example addresses:

       pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion
       sp3k262uwy4r2k3ycr5awluarykdpag6a7y33jxop4cs2lu5uz5sseqd.onion
       xa4r2iadxm55fbnqgwwi5mymqdcofiu3w6rpbtqn7b2dyn7mgwj64jyd.onion

   For more information about this encoding, please see our discussion thread
   at [ONIONADDRESS-REFS].

這是因為在 ECC 的安全性被廣泛認可後,ECC 的優點就被拿出來用在這次設計上了:

  • 256 bits 的 ECC key 強度大約是 3072 bits RSA key (以現在最好的攻擊演算法來估算)。
  • 直接放 public key 不需要經過 hash function 計算,可以避免掉 hash function 被找到 collision 時的風險。

於是因為 hostname 放的下,就硬塞進去了 XDDD

不過如果要玩的人需要裝 alpha 版本,目前的 stable 版本還沒有這個功能:

Tor as of version 0.3.2.1-alpha supports the next-gen onion services protocol for clients and services! As part of this release, ​the core of proposal 224 has been implemented and is available for experimentation and testing by our users.

V8 對 Hash Flooding 的防禦措施

Hash Flooding 問題是指 Hash 這個資料結構是可以被預測 collision 所造成的問題,在隨機的情況下會是 O(1) 的操作,在特定挑選故意讓他 collision 而變成 O(n),當有 n 個元素時,乘起來就會變成 O(n^2)。這算是一種阻斷攻擊 (DoS attack)。

在「About that hash flooding vulnerability in Node.js...」這邊提到了 V8 之前為了避免 Hash Flooding 的問題,關掉了 Startup snapshot 而造成的效能問題,以及後續的很多故事,最後找了長期的解法。

這個解法已經併入 Node.js 裡,預定下個包括的版本是 8.3.0:

The patch to re-enable startup snapshot has been merged into Node.js. It is part of the recent Node.js v8.3.0 release.

不過這表示現有的 LTS (4.8.4 以及 6.11.2) 還是... XD

歡樂的 md5crypt 密碼...

作者寫了一篇關於以前在 WHOIS 記錄上看到一串 $1$ 開頭的 md5crypt 密碼 XDDD:「I mean, why not tell everyone our password hashes?」。

Now the fields are filtered but this is a reasonably recent change. Prior to July 2015 the hashed passwords were shown to anyone who whois’d the maintainer object and used md5 passwords. Which was nearly all of them in my experience.

Mntner:         DTAG-NIC
Descr:          Deutsche Telekom Internet Services NIC
Admin-c:        KK281-RIPE
Tech-c:         HI56-RIPE
Auth:           MD5-PW $1$KQ3NSRfS$/bcvLAz2BKyf5HF4VkPMh/
Mnt-by:         DTAG-NIC
Referral-by:    RIPE-DBM-MNT

不知道有沒有人去跑看看... XD

話說 md5crypt 已經被認為不安全 (當初的發明人 phk 也有出來建議大家換掉了:「Md5crypt Password scrambler is no longer considered safe by author」),從目前 Hashcat 的攻擊速度就可以看出來... 找個最近的例子來說,可以參考「8x Nvidia GTX 1080 Hashcat Benchmarks」這篇。

Hashtype: md5crypt, MD5(Unix), FreeBSD MD5, Cisco-IOS MD5

Speed.Dev.#1.:  9918.1 kH/s (97.10ms)
Speed.Dev.#2.:  9830.1 kH/s (97.70ms)
Speed.Dev.#3.: 10017.4 kH/s (97.36ms)
Speed.Dev.#4.:  9986.5 kH/s (96.92ms)
Speed.Dev.#5.:  9976.8 kH/s (97.74ms)
Speed.Dev.#6.:  9889.2 kH/s (97.29ms)
Speed.Dev.#7.: 10010.5 kH/s (97.40ms)
Speed.Dev.#8.: 10083.0 kH/s (96.94ms)
Speed.Dev.#*.: 79711.6 kH/s

而隔壁的 bcrypt 對 Hashcat 的防禦性完全在不同等級:

Hashtype: bcrypt, Blowfish(OpenBSD)

Speed.Dev.#1.:    13094 H/s (47.51ms)
Speed.Dev.#2.:    13076 H/s (47.63ms)
Speed.Dev.#3.:    13292 H/s (46.88ms)
Speed.Dev.#4.:    13250 H/s (47.17ms)
Speed.Dev.#5.:    13296 H/s (46.86ms)
Speed.Dev.#6.:    13160 H/s (47.30ms)
Speed.Dev.#7.:    13260 H/s (46.98ms)
Speed.Dev.#8.:    13280 H/s (46.80ms)
Speed.Dev.#*.:   105.7 kH/s

直接相除是 754 倍左右。

以 85 個字元的組合計算 ([0-9A-Za-z] 62 個,特殊字元 22 個,加上空白 1 個),抗性多了 1.5 個字 (log85(754) 大約是 1.49)?如果以 62 個字元來看也有 1.6 個字,強了不少...

BitTorrent 對 SHA-1 的改善計畫?

最新一版的 Tails 不再支援透過 BitTorrent 下載,會被導去「Biterrant attack」這邊的連結,裡面有一些關於在 SHA-1 打穿後要怎麼判斷。

BitTorrent 的討論 (包括 BitTorrent 發明人 Bram Cohen 的參與) 則是在 GitHub 上:「Transitioning to stronger hash function · Issue #58 · bittorrent/bittorrent.org」,不過看起來連要用什麼 hash algorithm 的定案都還沒有啊... 而且二月底比較熱鬧一點,三月後都沒什麼動作了。

看起來短時間也不會有動作了...

對 SHA-3 的攻擊

隔壁棚剛順利打趴 SHA-1 (Google 與 CWI Amsterdam 合作,找到 SHA-1 第一個 collision),還是有人在針對比較新的演算法在攻擊:「SymSum: Symmetric-Sum Distinguishers Against Round Reduced SHA3」。

完整的 SHA-3 是 24 rounds,這次打的是 9 rounds 版本,雖然有段距離,但這等於是大進展:

Based on this we propose a new distinguisher called SymSum for the SHA3 family which penetrates up to 9 rounds and outperforms the ZeroSum distinguisher by a factor of four.

不過 SHA-3 用的人不算多,該不會在還沒成為主流就被打趴...

Archives