用 Percona XtraBackup 備份時用 compact 模式節省空間...

在「Feature preview: Compact backups in Percona XtraBackup」看到的,2.1 版會導入 compact backup 節省備份出來的空間 (目前是 2.0):

As you may know InnoDB PK (Primary Key) contains all data, and all secondary indexes are only subset of columns of Primary Key. So in theory we can store only PK, and re-build secondary indexes as we need. Well, now it is possible not only in theory.

secondary index 可以事後再建,所以有兩種表格會省下很多資源:

  • Index 很多的表格。
  • PK 欄位空間很大的表格 (像是用 VARCHAR(255) 當 PK)。

等出了再來研究看看對 Percona XtraDB Cluster (PXC) 重新同步可以加快多少...

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史,其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章:「Encrypt-then-MAC」,當時 Colin Percival 寫的時候大家還是不能理解,但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD

SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題:對 128bits CBC mode system (像是 aes128-cbc),任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161,論文是「Plaintext Recovery Attacks Against SSH」)

TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠,不過到了 2011 年時才被拿出來示範,也就是 BEAST attack。(CVE-2011-3389,在 ekoparty Security Conference 上的「表演」:「BEAST: Surprising crypto attack against HTTPS」,連結1連結2)

OpenSSLGnuTLS 所實作的 DTLS 在 2011 年也被炸到,其中 OpenSSL 是 100% plaintext recovery,GnuTLS 是 4%。(CVE-2012-0390,論文是「Plaintext-Recovery Attacks Against Datagram TLS」)

而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法,而且被證明 Provable security:Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。

附帶一提,其中 Provable security 這個詞,並非表示「可被證明是安全的」,在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低:以 Encrypt-then-MAC 的例子來說,如果 Encrypt 的部份用 DES,或是 MAC 用 CRC32,那麼 Encrypt-then-MAC 並不會提供更強的安全性...

總而言之,MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode),而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式,有些有專利問題,有些演算法看起來就很複雜 (於是就容易出包),其中 Encrypt-then-MAC 看起來是個還不錯的方案...

把 PEM Private Key 檔轉成 SSH Public Key 格式...

RSA 中,單獨靠 Private Key 是無法算出 Public Key 的,不過在 PEM 檔裡因為都有紀錄,所以可以取出:

openssl rsa -in aws.pem -pubout

不過取出的格式需要再轉一次讓 OpenSSH 可以吃:(參考「Convert pem key to ssh-rsa format」這篇的方法)

ssh-keygen -f aws.pub -i -m PKCS8

雖然 ssh-keygen 不接受 - 當 stdin,但可以利用 /dev/stdin 直接串起來:

openssl rsa -in aws.pem -pubout | ssh-keygen -f /dev/stdin -i -m PKCS8

結果回頭用 Google 提供的 Chrome 就好了...

因為目前 Ubuntu 12.04 的 chromium-browser 還是 18.0,所以在「Ubuntu 上的 Chromium Stable Channel 與 Dev Channel」這篇試著裝新版的 chromium,結果發現問題不少...

stable 版本容易 core dump 掛掉,dev 版本感覺是 connection leak... 可用的 connection 變少後,網站速度卡在 parallel connection 不夠。

結果晚上被 gasolwu 說可以裝 Google 官方的版本,才發現從 Google 下載下來雖然是 deb,但安裝時會自動增加 apt key (好邪惡啊) 並且設定 apt 機制更新...

總算能用 21.0 了...

60 公尺外,拍照攝影就可以重製鑰匙...

2009 年在 Schneier on Security 上看到的文章,這幾天跟同事剛好有提到:「Reproducing Keys from Photographs」,相關的技術更早前就有,只是沒有這麼遠。

在論文裡是在 195 feets 外 (約 60 公尺) 架設儀器拍攝鑰匙,利用這些資訊重製鑰匙資訊:

拍攝的設備是:

Figure 7: Telephoto setup consisting of C5 spotting scope, Televue PowerMate 4X Tele-extender, and Cannon 40D Digital SLR. Entire system folds up into two small cases and weighs 16 pounds.

儲存密碼的方式

主要是參考「Cryptographic Right Answers」這篇給的建議:

Password handling: As soon as you receive a password, hash it using scrypt or PBKDF2 and erase the plaintext password from memory.
Do NOT store users' passwords. Do NOT hash them with MD5. Use a real key derivation algorithm. PBKDF2 is the most official standard; but scrypt is stronger.
Please keep in mind that even if YOUR application isn't particularly sensitive, your users are probably re-using passwords which they have used on other, more sensitive, websites -- so if you screw up how you store your users' passwords, you might end up doing them a lot of harm.

其中 scrypt 是作者自己發展的演算法,這邊看看就好。

你可以用 PBKDF2 (RFC 2898)。這邊假設的前提是,你不需要常常重複計算使用者的密碼是否正確。在這個前提下,我們可以把演算法弄得很複雜,而且很耗時,要複雜到用硬體加速也無法產生實質上有效的攻擊。

如果你對密碼學這個領域並不熟,Colin Percival 這篇文章可以拿來當做起點,文章裡面告訴你,某些類型的問題會用某些工具解決。

addons.mozilla.org 的 Comodo SSL Certificate 被放出 Private Key

之前被人破台,利用 Comodo CA 生出 addons.mozilla.org SSL certification 的 private key 被放出來了:「Comodo Hacker releases Mozilla certificate」。借 Netcraft 的圖:

Firefox 的 revoke 機制不怎麼完善,對於用 Firefox 的人,直到 Mozilla 有新的方法解決之前都必須很小心了 :/

AWS EC2 可以匯入自己的 SSH public key 了...

今天 AWS EC2 一口氣丟出一堆小功能:

其實這些功能都沒什麼大不了的,Idempotent Instance Creation 可以避免重複產生 instance,而 Resource Tagging 暫時想不到用途,Filtering 則是 describe 的功能加強...

對現在最有幫助的是第四個,ssh 時可以不用指定 -i .ssh/ooxx.pem 算是有直接影響的吧?目前還不能透過 Web Console 匯入,必須用 ec2-import-keypair 指令匯入。