icebox

the-grail-of-forward-secrecy

quininer kel — Wed, 12 Sep 2018 09:23:29 -0000

0-RTT and Forward Secrecy

Tue Sep 11 00:43:19 2018

前向保密是一個已經被人熟知的安全特性。基於密鑰交換的前向安全廣泛存在於各種密碼協議之中，例如 TLS、Signal Protocol、WireGuard。

Session based

一般我們所說的前向保密方案是基於會話的，每次會話通過握手產生一個獨立的會話密鑰。會話結束之後銷毀該會話密鑰便可保證前向保密。

但基於會話的前向保密並不適用於所有場景，很多情況下我們沒有握手的條件、或者通信開銷非常之大。例如 Email、IoTInternet of Things。

“如何在這些情況下保證前向保密”成爲了一個聖盃級的公開問題，數十年來衆多密碼學家爲此付出心力。

幸運的是，這並非是無可能的。

Interval based

基於時間段的前向保密方案聽起來不太優雅，但非常實用。

基本思路是將密鑰分成不同的時間段。在某個時間段過去之後，銷毀該時間段對應的私鑰，從而達到前向保密。

Weekend scheme

我相信這個方案在歷史上被設計過不止一次，最後一次見到它是在 openpgp 討論中 ¹。我不清楚它的名字，本文將之稱爲週末方案。

用戶每逢週末更換一次自己的密鑰，並將新的公鑰公佈在網絡上。其他用戶加密時必須檢索對方的最新公鑰。

這個方案很簡單，但缺點也很明顯

要求其他用戶加密時有檢索最新公鑰的能力
多設備不友好

每次都要更新公鑰實在是太麻煩了，那可不可以再給力點？

HIBE scheme

有的！我們首先通俗的介紹一下 HIBEHierarchical Identity Based Encryption²。

HIBE 有一個中心的 PKGPrivate Key Generator，它可以通過 ID 產生所有用戶的私鑰。每個用戶也能通過子用戶的 ID 產生子用戶的私鑰，自然的，子用戶不能恢復父用戶的私鑰。

其他用戶加密時只需要知道 MPKMaster Public Key 和子用戶的 ID。

我們可以基於 HIBE 構造出一個不需要更換公鑰的前向保密方案。

用戶加密時根據當時的時間產生用戶 ID，並用此進行加密。例如

CT = enc(MPK, ["2018", "9", "10"], MSG)
用戶解密時，根據 PKG 或父用戶的私鑰產生對應 ID 的私鑰，並用其解密，例如

SUB_SK = keygen(SK, ["2018", "9", "10"]) MSG = dec(SUB_SK, CT)
當一個時間段過去時，用戶先用 PKG 或父用戶的私鑰產生剩餘所有子用戶的私鑰，並銷毀 PKG 和父用戶的私鑰。例如

(_, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC) = keygen_year(YEAR) delete(YEAR)

完美！這個方案完全解決了週末方案的兩個缺點，其他用戶不需要時時檢索對方的最新公鑰，用戶自己也不需要在多個設備之間同步自己的新私鑰。

但是基於時間段的方案有一個共同的缺點，

試想一個情景，alice 在 2018年9月30號執行加密，但由於各種原因到達 bob 手中時遲了一日。可惜當時 bob 已經將 9月所對應的私鑰銷毀了，所以他無法解密 alice 的密文。

這顯然不是我們想要的效果，那可不可以再給力點？

Puncture based

除了時間段這個思路之外，我們還有沒有其他實現前向保密的辦法呢？

可穿刺加密是另一種思路，原始狀態下的私鑰包含所有信息，可以解密所有密文。當用戶成功解密一個密文後，用戶可以從私鑰中消除（我們將之稱爲穿刺Puncture）一部分信息，使得新私鑰不能解密該密文。

Binary Tree Encryption scheme

BTEBinary Tree Encryption^3,4 是一個有趣的設計，它同樣基於 HIBE。

它相當於使用 IBE 產生一個巨大的私鑰集，然後使用和密文對應的 tag 確定其中一個 ID 或密鑰（通過一個 Hash）。

穿刺時，通過 Hash 該 tag 來確定私鑰，然後銷毀它。

但是一個夠用的私鑰集相當大，假設一個私鑰大小爲 64b，我們期望有 2^32 個私鑰可以用，那最終儲存這個密鑰集我們需要 274877.907 MB。

這是不現實的。

但我們可以通過 HIBE 來懶惰式的生成私鑰，這可以有效的將最壞情況下的密文尺寸降低一半。

Bloom Filter Encryption scheme

BFEBloom Filter Encryption⁵ 是 BTE 的一個有趣變種。

它使用一個 Bloom Filter 來降低 tag 的碰撞率，代價是較快的空間使用速度。

加密時，使用 IBBEIdentity Based Broadcast Encryption 將消息廣播加密給 bloom filter 選擇出的 k 個 ID。
解密時，使用 k 個 ID 中其中一個可用的 ID 進行解密，若均不可用則解密失敗。
穿刺時，將這 k 個 ID 對應的私鑰銷毀。

無論如何，基於 IBE 的可穿刺加密仍有相當大的私鑰尺寸。那，可不可以再給力點？

Non-Monotonic ABE scheme

照例我們先簡單介紹一下 NM-ABENon-Monotonic Attribute based encryption⁶。

ABE 就像 IBE，但它使用屬性Attribute 而不是 ID 來進行加密。 KPKey Policy-ABE 是指是加密時爲密文指定屬性，只有符合某個規則的私鑰可以解密。

而一般 ABE 的規則是單調的，即是說只有 And 和 Or 兩種規則。非單調性 ABE 的有趣之處是支持 Not 規則。

有了 NM-ABE，構建可穿刺加密變得非常直觀。加密解密時和普通 ABE 一樣。穿刺時，只需在私鑰規則中增加一條 Not(tag)。⁷

至此，該方案的私鑰大小只會隨着穿刺次數線性增長，而不會爆炸。

Binary Tree Bloom Filter Encryption?

我們可以將 BTE 和 BFE 結合，利用 HIBBEHierarchical Identity Based Broadcast Encryption 構造出 BTBFEBinary Tree Bloom Filter Encryption。

理論上這可以將 BFE 的私鑰尺寸降得更低，但我沒有找到合適的 HIBBE 方案實現它。

Perfect?

我們介紹了數個在限制情況下保證前向保密的加密方案，看起來似乎足夠讓人們戴着鐐銬跳舞。

如果這些方案足夠高效，是不是意味著我們再不需要握手，無延遲的 0-RTT 通信可以全面推廣呢？

很遺憾並不是，這些方案只能保證“前向保密”。

而基於會話的方案除了前向保密之外還保證了“弱後向保密”，即在泄漏長期私鑰時，若敵手在之後沒有參與協議，那協議仍能保證之後密文的保密性。

當然，這一切在量子敵手面前都毫無意義。

ene

quininer kel — Fri, 03 Aug 2018 15:09:57 -0000

Encrypt on Email

什麼是 ENE？

ENE 是一個實驗性質的、設計用於郵件的、端到端End to End加密工具。它基本上是我設想中的 OpenPGP 2.0，針對 PGP 的弱點作出了一些改進。

郵件是一個單次、無狀態的通信方案，這意味著爲它設計加密方案無法達到很多常見的安全要求。例如經常被提到的完美前向保密Perfect Forward Secrecy。事實上放寬其中一個限制，我們就可以做到很多，例如 OpenPGP 實際上有一個有狀態的前向保密方案¹。

但在這些條件下，我們可以做的事情並不多。

在早期，我們滿足於簡單的 KEMKey encapsulation mechanisms + Encrypt 加密方案，這些方案缺失了身份認證、完整性驗證。

而在 2018 年，我們可以做得更好。

ENE 將會提供：

認證密鑰交換Authenticated Key Exchange
可否認的郵件認證Deniable authentication
郵件完整性Integrity
具有 Nonce-misuse Resistant 的加密方案
實驗性的 Post-quantum 密碼套件

我們需要認證？

試想一個場景，Alice 向 Bob 發送一個沒有認證的加密消息，Mallory 可以輕鬆的攔截並轉發這個消息給 Bob。 Bob 會認爲這個消息是由 Mallory 發送的。

這是由於缺乏身份認證導致的。

可能很多人會覺得加簡單的增加一個簽名會解決所有問題，但並不是。簡單的簽名方案有兩個缺點

可否認性²的丟失
- 當你使用私鑰簽名一段消息時，實際上你背負了一定的法律責任。你將無法否認那段消息出自於你的手筆。
Surreptitious Forwarding Attack^3,4
- Mallory 可以將 Alice 的簽名剝離，使用自己的簽名代替。
- 可能有人認爲 Sign-then-Encrypt 將會解決這個問題，但若加密方案達不到 CCA⁵，那它仍無法防止此攻擊。

ENE 有四種認證方案，用戶可以靈活選擇自己想要的安全性。

One-Pass Authenticated Key Exchange^6,7
- 一次通信的認證密鑰交換有良好的性能，因爲它不涉及複雜的簽名算法。
- 由於只能通信一次，我們仍無法做到完美前向保密。但我們可以做到發送者前向保密，這至少和公鑰加密一樣好。
- one-pass ake 只提供隱式認證，這意味著它無法抵抗 KCIKey Compromise Impersonation攻擊⁸。
- one-pass ake 是 ENE 中最弱的認證方案，但它仍能防禦大多數攻擊。你應該用它代替早期郵件加密中無認證的加密方案。
Signature-based Authenticated Key Exchange^9,10
- 在密鑰交換中加入簽名可以做到顯式認證。這個增強將可以抵抗 KCI 攻擊。
- 簽名內容不包括消息，這意味著該方案仍能保持消息的可否認性。
Signature Key Exchange and Message
- 在方案2 的基礎上，簽名內容包括明文消息。這將保證消息的不可否認性Non-Repudiation。
Signature Only
- 只簽名明文消息，不作任何加密。

我們需要 AEAD？

我相信我不需要在 8102 年贅述完整性驗證的重要性。

EFAIL 就是一個未能很好處理完整性驗證導致的漏洞。

實際上 OpenPGP 有自己的完整性驗證方案 MDC¹¹，但在大多數應用中只當作警告處理，並且存在降級攻擊¹²。而在 ENE 中，我們可以使用更現代的 AEAD 方案，更好的保證完整性。

關於 AEAD¹³ 的研究已經有很多年，更多的安全性質被提出，例如 Nonce-misuse Resistant¹⁴。

由於郵件無狀態的特點，我們只能隨機的產生 nonce。對於某些加密算法而言，nonce reuse 的後果是毀滅性的，例如 AES-GCM¹⁵。雖然我們可能沒有如此大量的郵件以導致生日攻擊，但使用一個 Nonce-misuse Resistant AEAD 將可以免疫這個問題。

我們需要 Post-quantum？

衆所周知，量子機可以打破所有當前流行的公鑰算法。屆時，所有使用 RSA/ECC 加密的郵件都將無法保證保密性。因此，有必要在實用的量子機出現之前進行防禦。

一般有兩種方法來對抗量子機

使用預共享密鑰。
使用 Post-quantum 密鑰交換¹⁶。

考慮到郵件的使用場景，預共享密鑰在很多情況下不太現實。因而使用 Post-quantum 算法是一个有意义的选择。

ENE 是完美的嗎？

不是！

ENE 未來仍有很多工作要做。例如

子密鑰支持
完全的前向保密^17,18
郵件列表Mailing list加密支持
側信道攻擊Side-Channel attacks抗性
協議形式化驗證Formal verification

ENE 是一個非常年輕的工具，一切在未來必將發生變化。

爲什麼不用 ENE？

ENE 不是萬能的。它被設計用於加密郵件，不是 PGP 的完全替代品。

Web of Trust¹⁹
- 我不打算討論 Web of Trust 的好壞。
- ENE 不是信任系統，不考慮如何建立信任關係。
- 若需要，你可以使用 PGP 簽署 ENE 公鑰。
爲 git commit、壓縮包以及其他公鑰簽名
- ENE 可以做，但在這些方面不會比 PGP 有什麼優勢。
- 當然，你也可以使用 pbp。
加密巨大的文件
- 通常郵件文本不會太大，所以 ENE 不考慮這一點。
- 當然，這不意味著 GPG 適合做文件加密。
需要可靠的、穩定的加密方案
- ENE 非常不穩定！隨時可能發生變化。
- “現代 PGP” 依然是最好的選擇之一，例如 Sequoia。

ENE 是開源的，代碼託管在 Github。

tamarin-and-badake

quininer kel — Fri, 15 Jun 2018 04:15:41 -0000

如何設計一個壞協議

Wed Jun 13 19:44:31 2018

近幾日看 The 8th BIU Winter School on Cryptography 的 slide，這期冬令營主要內容是協議設計。

冬令營第二講 Implicitly Authenticated KE Protocols 拋磚引玉，提出了一個相當簡潔的兩消息隱式帶認證密鑰交換Implicitly Authenticated Key Exchange協議，

後文將稱之爲 BADAKEBasic A-round Diffie-hellman Authenticated Key Exchange。

這是一個相當乾淨的協議，甚至可能大家自己就在實踐中設計過類似的協議。但這不是一個安全的協議。

slide 中已經舉出了一些該協議的攻擊，這些攻擊並不那麼直觀。

Define

在描述這些攻擊之前，我們先澄清一些定義。

隱式帶認證密鑰交換: 與顯式認證密鑰交換不同，隱式認證協議不會在協議執行中顯式的失敗，但只有雙方身份正確時會生成相同的密鑰。
認證協議安全要求: 一個合格的認證協議應該在協議完成之後保證
- 基本僞裝抗性Basic Impersonation Resistance: 若 A 正確執行協議，當敵手不知道 A 的長期密鑰時，敵手不可以僞裝成 A。
密鑰交換協議安全要求: 一個合格的密鑰交換協議應該保證，
- 完美前向保密Perfect Forward Secrecy: 長期密鑰泄漏時，不會影響之前會話密鑰的安全性。
- 弱前向保密weak Perfect Forward Secrecy: 由於兩消息的認證密鑰交換協議無可能滿足 PFS，所以對於這些協議，退而求其次，我們只要求 wPFS。若敵手在長期密鑰泄漏之前沒有參與協議，那長期密鑰泄漏時，不會影響之前會話密鑰的安全性。
- 已知密鑰安全Known-Key Security: 會話密鑰泄漏時，不會影響長期密鑰及其他會話密鑰的安全性。
- 臨時祕密揭露抗性Ephemeral Secrets Reveal Resistance: 臨時密鑰泄漏時，不會影響長期密鑰及其他會話密鑰的安全性。
- 未知密鑰共享Unknown Key-Share抗性: 當 A 和 C 協商出會話密鑰時，A 不會認爲該密鑰是與 B 協商得到的。

Signature + DH

在分析 BADAKE 前，slide 先給出了一個簡單的簽名與密鑰交換的組合協議。這個協議在簽名中加入了目標身份，以避免交錯攻擊。

但這個協議仍然是不安全的。

當 A 的臨時密鑰 x 泄漏時，攻擊者可以重放消息 g^x, SIG{A}(g^x, B)，與 B 進行握手。從而達成僞裝 A 身份的目的。

一般情況下防止重放攻擊的最好方案是添加一個 challenge，但這需要增加一輪通信。

這個例子說明了使用 Signature + DH 的簡單組合無法實現安全的兩消息帶認證密鑰交換。

Implicitly Authenticated DH

slide 給出了 BADAKE 的兩種簡單組合方式。

第一種組合方式相當簡單， K = H(g^ab, g^xy)

slide 中描述它受到 Open to known key and interleaving attacks 的威脅。一開始我不太明白這個攻擊如何實現。

藉助 tamarin，我們可以輕鬆找到針對這個協議的多個攻擊方案，這裏我們舉出兩個

反射攻擊

A 向 B 發起兩個握手請求，敵手將這兩個請求作爲響應發回給 A。

A 不會知道他正在和自己通信。（呆萌

會話密鑰揭露時的交錯攻擊

這圖片中描述的攻擊與 slide 可能有所不同。

此攻擊需要 B 在握手結束之後泄漏會話密鑰。

B 向 A 發起兩個握手請求，敵手將一個請求作爲響應發回給 B。兩個會話產生相同的密鑰，結束其中一個會話，B 泄漏會話密鑰 K。敵手使用該密鑰繼續與 B 通信。

最終達成僞造 A 身份的目的。

KCI Attack

第二種組合方式添加了角色因素，可以對抗反射、並行會話等攻擊方式。 K = H(g^ab, g^xy, g^x, g^y)

這相比第一種組合方式要好一點，但仍不是一個理想的 AKE 方案。

slide 中提到了密鑰泄漏僞裝攻擊Key-Compromise Impersonation。簡單來講就是，在 A 的長期密鑰泄漏之後，敵手不但可以僞裝成 A 與 B 通信，也可以僞裝成 B 與 A 通信。

這個漏洞在使用密鑰交換作認證的協議裏很常見，例如 Tox 就有這個問題。

很多人會覺得泄漏長期密鑰之後，協議可以不保證認證安全性。但一個好的認證協議應該要避免這一點。

上文的內容在冬令營的演講中只佔不到半分鐘時間，而後面關於 MQV、HMQV 的各種變種佔了將近兩個小時。

設計一個好的密碼協議並不是一件容易的事情。

而想要設計一個壞協議？只需要拍腦袋式的想一個簡潔的協議就可以了。

wasm-stack-overflow

quininer kel — Thu, 10 May 2018 18:31:44 -0000

WebAssembly StackOverflow

Mon Apr 30 16:50:47 2018

WebAssembly 是一個設計運行在瀏覽器上的類彙編語言，藉助它可以令 C / C++ 之類的語言運行在瀏覽器上，以期得到性能提升。

新功能自然會引入新攻擊面，可以預見 C / C++ 上經常出現的緩衝區溢出並不會在 WebAssembly 上消失。

有什麼不同

WebAssembly 同常見的彙編有很多不同的地方，例如

它是一個 Stack Machine
它使用 Linear Memory
指令與數據隔離
…

因爲第三點，WebAssembly 在一定程度上是 Harvard architecture，這爲 WebAssembly 帶來了很大的安全優勢，但棧溢出仍是可能的。

一個例子

我們舉個虛構的例子來證明 WebAssembly 棧溢出的可行性。

Rust 代碼:

```rust // ...

[wasm_bindgen]

pub fn hash_with_key(key: &str, data: &str) -> u32 { let mut val = [0; 32]; let key = key.as_bytes(); let data = data.as_bytes();

val[..3].copy_from_slice(&key[..3]);
val[3] = 0x33;
val[4..][..data.len()].copy_from_slice(&data);

js_hash(&val)

}

[wasm_bindgen]

pub fn table_index(i: usize) -> u8 { let a = [b'a', b'd', b'c', b'b']; unsafe { *a.get_unchecked(i) } } ```

WebAssembly 的 wat 格式基於 S-expression，指令精簡，與傳統彙編相比，相對容易閱讀。

但鑑於編譯出的 wasm 較長，下面我們只看我們關心的內容，完整的內容可以看這裏。

(global (;0;) (mut i32) (i32.const 1050544))

指令 global 定義了一塊可變的全局內存。其中 1MB 是棧空間，剩下的是數據段。

``` (func $hash_with_key (type 2) (param i32 i32) (result i32) (local i32 i32 i32) get_global 0 i32.const 32 i32.sub

;; ...

    get_local 2
    get_local 0
    i32.load16_u align=1
    i32.store16
    get_local 2
    get_local 0
    i32.const 2
    i32.add
    i32.load8_u
    i32.store8 offset=2

;; ...

) ```

函數 hash_with_key 在棧上開闢 32bytes，將 key 寫入棧上，而退棧時未將其清零。

``` (func $table_index (type 4) (param i32) (result i32) (local i32) get_global 0 i32.const 16 i32.sub

;; ...

i32.const 12
i32.add
get_local 0
i32.add
i32.load8_u)

```

函數 table_index 在棧上開闢 16bytes，偏移 12bytes 讀取一個 byte。

簡單分析可以知道，在用戶正常調用 hash_with_key(..) 之後，攻擊者只需要調用 table_index(16 - 12 - 32 + x) 便可獲得寫入棧上的 key。

侷限

雖然棧溢出是可行的，但指令與數據的分離，使得我們只能讀寫棧內容而不能改變控制流。這意味著 ROP、return2libc 之類的技巧不再有效，棧溢出將只能在邏輯方面造成一些影響，危險度下降不止一個等級。

柳暗花明

而 WebAssembly 想要支持函數指針、虛函數、trait 對象，就必須引入一些動態方案。

WebAssembly 的方案是將所有需要動態使用的函數放入 Table，在運行時通過引索指定，並且在調用時會檢查函數簽名。

這個設計試圖在最大程度上降低風險，但無可避免的爲攻擊者開了一扇窗。

XSS Game

基於 WebAssembly 棧溢出，我做了一個簡單的 XSS Challenge，源代碼託管在 wasm-xss-game。有興趣的讀者可以一試。

本文有意忽略堆溢出，以避免引入衆多 Allocator 的複雜性。
作者不熟悉二進制安全、計算機原理。胡言亂語不知所云，有錯勿怪。

Stratis

quininer kel — Sun, 15 Apr 2018 16:27:40 -0000

Stratis

Sun Apr 15 18:14:39 2018

Stratis 是 redhat 放棄 Btrfs 之後推出的代替品，使用類似 LVM 的方案來提供有如 btrfs、zfs 般強大的功能。

其實 Stratis 釋出 0.5 有一段時間了，今次抽出時間來嚐下鮮。 Stratis 目前沒有面向用戶的文檔，故久違的寫一篇博文用以記錄。

準備工作

從 AUR 安裝 stratisd 同 stratis-cli，然後啟動 stratisd

$ systemctl start stratisd

開始

首先我們清理要用的塊設備

$ sudo wipefs -a /dev/sda

但當前版本創建 pool 的時候會碰到錯誤，stratisd 認爲這個塊設備已經被使用

$ stratis pool create stratis /dev/sda Execution failed: 1: Device /dev/sda appears to belong to another application

根據 issue，如果塊設備的前 4/8k 字節未置零，stratisd 不會使用它。

知道原因就簡單了，我們將它置零

$ dd if=/dev/zero of=/dev/sda bs=1024 count=8

然後就可以正常創建 pool

$ stratis pool create stratis /dev/sda $ stratis pool list Name Total Physical Size Total Physical Used stratis > 238.47 GiB 52 MiB

隨後創建 fs

$ stratis fs create stratis storage $ stratis fs list stratis Name storage $ la /dev/stratis/stratis/storage Permissions Size User Date Modified Name lrwxrwxrwx 9 root 15 4月 18:21 /dev/stratis/stratis/storage -> /dev/dm-6

完成

創建完成，直接掛載就可以使用啦

$ sudo mount /dev/stratis/stratis/storage /run/media/quininer/storage $ sudo chown quininer /run/media/quininer/storage

用得開心。 ;-)

基于serviceWorker的缓存投毒

quininer kel — Tue, 06 Oct 2015 06:49:18 -0000

基于serviceWorker的缓存投毒

Sat May 2 20:52:57 2015

前几天才察觉到 Chromium 42 已经支持 Fetch API 了，鉴于我早就想用 Fetch 代替 Ajax，所以今天把 ice.js 的$.http部分改用 Fetch 实现了。

没想到的是 Firefox 目前还是 37 版本，不支持 Fetch。所以不得不引入一个 fetch.js 做兼容。

以上都不是重点

和 Fetch 搭配使用的还有一个有趣的东西，serviceWorker。其实早就在某牛的博客中看到过，当时没有太深想，也因为没有实际上支持 Fetch 的浏览器，所以并没在意。

因为上文的事件，想起了这东西。简单来说，这个API能拦截 HTTP Request，并返回预定的 Response。

自然，Response 里也包括 HTTP Headers，所以只要简单的在 HTTP Header 里控制一下缓存时间即可，比如

Cache-control: max-age=99999999999999999999999999999999999999

下面是一些截图

POC: cache tests

实际上也并非所有 HTTP Header 都能使用，这里有一个禁表。

~~总之这套东西不管从哪方面来说都好方便。 :)~~

实际上

收回上一句话。和FD测试了一会，上面的POC看上去很美，实际上serviceWorker限制多多。

比如

只能拦截同源且子路径的 Requests
scriptURL 必须同源，且原则上必须是实际存在网络的资源
worker.js 的处理和一般 script 处理不一样，必须符合规范，否则将会静默的失败
serviceWorker只能工作在开发环境localhost 和 HTTPS 下

且不说要求 HTTPS 这样涉及协议的奇葩规定，要求 scriptURL 必须实际存在这一点就让利用变得几无可能。

实际上使用也会变得极不方便，难以和各种完全由 JavaScript 生成的框架整合。也没有实际上解决安全问题。

我倒是更希望 scriptURL 能允许使用 Blob，而Cache被加入 HTTP Header 禁表。

Surface

quininer kel — Tue, 21 Apr 2015 09:28:47 -0000

Surface Pro 3

Mon Mar 30 17:19:12 2015

事情是這樣的，我買了一臺 Surface Pro 3，並給它裝了 Arch Linux。

關於Windows

用了兩天 Windows 8，其實感覺還不錯，按照之前的想法，試圖裝上 Cmder 和 msys2 來讓 Windows 上的終端也達到可用狀態。

效果不盡人意，

cmder 不知是字體或是什麼問題，Vim 下字符會混亂，有點像不等寬字體，而且還有鍵捕獲不到以及亂碼的奇怪問題
msys2 的包太少，完全不夠用
mingw 不會用= =
一開始 msys2 用 pacman 裝的 Mingw Python 找不到，需要手動把/mingw64/bin加入 PATH
試圖安裝上 yaourt，但是依賴的依賴 yajl 編譯報錯，似乎還要做許多設置

雖然 Windows 的觸屏體驗確實很棒，但是我早有裝 Arch Linux 的想法。所以上面的問題只是藉口。

關於Arch Linux

自從 Debian 換成 Arch Linux 之後便很喜歡。

Secure Boot

開機時音量鍵上 + 開機鍵進 UEFI 關掉就好了，雖然不關也能通過這個方法來啓動，但是實際上安裝完成之後依然會提示錯誤。

Install

雖然 reddit 上都說 WiFi 驅動在 3.19 內核才被合併，但是被 #archlinux-cn 頻道的 Feb-Chip 告知親測 Arch Linux 目前 3.18 內核的鏡像也能直接使用。 livecd 裏的 tty 下不能使用 Type Cover 鍵盤(猜測 3.19 內核之後就可以了)，所以使用 SD卡引導。和 U盤一樣，音量鍵下 + 開機鍵即可。

安裝過程完全參考新手指南，沒有碰上特殊問題。

KDE

HiDPI 依然按照 wiki 配置。

Firefox 效果不錯，而Chromium 效果糟糕，--force-device-scale-factor=2 就像被直接放大，沒有任何優化。比較好的方案是手動把網頁調到 175% 的大小。

電磁筆和觸屏幾乎完美。可惜沒有什麼對觸屏有優化的應用。這一點 Chromium 做的比 Firefox 好。配置一下可以讓電磁筆的按鈕起些作用。

當然 Type Cover 也要配置。~~不過我碰到了一些問題，一旦碰到 Type Cover 的觸摸板，X 便段錯誤崩潰了。我沒有找到類似的案例，推測是個例。~~

此問題已解決，更新 linux-surfacepro3 內核時重新配置了一下 /etc/X11/xorg.conf.d/50-synaptics.conf，觸摸板使用正常~

Kernel

編譯 aur 裏的 linux-surfacepro3 內核，最主要的是打上了電源補丁，終於可以看到電量了。

装内核時碰上一個坑，/tmp 掛載的大小只有 2G，因爲之前從 aur 打包了幾個軟件而內核又很大，所以打包 linux-surfacepro3 時塞滿了 /tmp，導致打包失敗。編譯了兩次之後才發覺.. 默默修改 /etc/yaourtrc 中的TMPDIR，

TMPDIR="$HOME/Aurs"

Battery

在 Windows 下粗略計過一下續航，平常使用瀏覽網頁確實能有 8h 之長。換到 Linux 之後，用秒錶計算，提示 10% 的電量時，续航 4:29:59 。其中包括 40m- 的 FEZ 遊戲時間。

估計用 laptop-mode 之類的動態調頻能延長一些續航。

最後，編譯 YCM 只用了 2分8秒，而上一個筆記本需要 5分鐘左右。

寫完博客第二天 linux-surfacepro3 就更新了，不得不再編譯一次內核。過程順利。

順便找到一個自动旋转脚本，雖然不夠流暢，但也可用。

剩下唯一的問題就是 KDE 缺少一個好用的屏幕鍵盤了吧。

在 Laptop-mode 下測試，正常使用至 10% 電量，續航 6:21:40。

參考

Google-Cloud-Security-Scanner

quininer kel — Tue, 21 Apr 2015 09:28:37 -0000

Google-Cloud-Security-Scanner

Thu Mar 5 14:12:39 2015

一回来上推就看到个有趣的东西——Google Cloud Security Scanner，虽然目前只是Beta，主要只有XSS检测和分析功能，不过怎么说也是Google出品。

亲测一番效果一般，可以选择前端测试环境。有一点比较麻烦，目前只允许扫描自己有权限的Gae应用。不过只要用Gae做个Proxy应用就能随意扫了。

没有太大亮点。不过比上不足比下有余，比起市面上大部份云扫描器算是好得多了。

其实用asyncio写了半个Proxy应用来着，才反应过来Gae没有Python 3.4。在Github里找了个成品，效果不错。

关于expressjs的一个小坑

quininer kel — Tue, 21 Apr 2015 09:28:15 -0000

关于expressjs的一个小坑

Tue Dec 9 01:07:53 2014

都知道在PHP里，/?key[arr]=value 会被解析为

array(1) { ["key"]=> array(1) { ["arr"]=> string(5) "value" } }

却一直没注意到expressjs里也会如此，

// GET /shoes?order=desc&shoe[color]=blue&shoe[type]=converse
req.query.order
// => "desc"

req.query.shoe.color
// => "blue"

req.query.shoe.type
// => "converse"

而在req.query里仅仅是这样不太显眼的一笔带过，似乎嵌套解析已成标配。但是不得不说的是嵌套解析至少在Node.js里很危险。

例如

app.get('/', function(req, res){
    sql.find({_id:req.query.id})
    .exec(function(err, data){
        res.json({data:data});
    });
});

访问/?id[$ne]=1则会返回不该有的数据，正如这里。

当然这不是mongodb的问题，参数的属性也可能被劫持

app.get('/', function(req, res){
    if(req.query.name.length <= 5){
        // TODO
        res.json({'err':null, 'name':req.query.name});
    }else{
        res.json({'err':'名字过长！'});
    };
});

使用/?name[length]=1即能绕过这个名字长度的限制。

同样的利用方法在更奇怪的环境可能会造成更严重的后果，最终导致code injection也并非不可能。
大概是意识到了这点，开发团队在下一个Web框架koa里取消了对嵌套解析的支持。
后续分离的cookie-parser也不支持嵌套解析。

最后，我的粗略的解决方案是

app.get('/', function(req, res){
    var name = (typeof req.query.name == 'string')?req.query.name:undefined;
    // TODO
});

或是使用中间件

app.use(function(req, res, next){
    for(var i in req.query)if(typeof req.query[i] != 'string')delete req.query[i];
    for(var i in req.body)if(typeof req.body[i] != 'string')req.body[i] = JSON.stringify(req.body[i]);
    next();
});

总之，务必先验证req.query.name，req.body.name以及req.param('name')的类型

ArriettySong

quininer kel — Tue, 21 Apr 2015 09:27:02 -0000

icebox

the-grail-of-forward-secrecy

0-RTT and Forward Secrecy

Tue Sep 11 00:43:19 2018

Session based

Interval based

Weekend scheme

HIBE scheme

Puncture based

Binary Tree Encryption scheme

Bloom Filter Encryption scheme

Non-Monotonic ABE scheme

Binary Tree Bloom Filter Encryption?

Perfect?

ene

Encrypt on Email

什麼是 ENE？

我們需要認證？

我們需要 AEAD？

我們需要 Post-quantum？

ENE 是完美的嗎？

爲什麼不用 ENE？

tamarin-and-badake

如何設計一個壞協議

Wed Jun 13 19:44:31 2018

Define

Signature + DH

Implicitly Authenticated DH

KCI Attack

wasm-stack-overflow

WebAssembly StackOverflow

Mon Apr 30 16:50:47 2018

有什麼不同

一個例子

[wasm_bindgen]

[wasm_bindgen]

侷限

柳暗花明

XSS Game

Stratis

Stratis

Sun Apr 15 18:14:39 2018

準備工作

開始

完成

基于serviceWorker的缓存投毒

基于serviceWorker的缓存投毒

Sat May 2 20:52:57 2015

以上都不是重点

实际上

Surface

Surface Pro 3

Mon Mar 30 17:19:12 2015

關於Windows

關於Arch Linux

Secure Boot

Install

KDE

Kernel

Battery

參考

Google-Cloud-Security-Scanner

Google-Cloud-Security-Scanner

Thu Mar 5 14:12:39 2015

关于expressjs的一个小坑

关于expressjs的一个小坑

Tue Dec 9 01:07:53 2014

ArriettySong

Arrietty'sSong

Sun Sep 21 17:20:47 2014