［知行合一］（六之四）

國安法第一審繼續就「光復香港。時代革命」八個字的意義，繼續進行討論。控方由嶺大學者劉智鵬以歷史學者身份，早前指出「光時」有分裂國家意思；而辯方的港大學者李詠怡 (Eliza)則已作供進入第三天。今天下午，和Eliza一起撰寫專家證人報告的另一位學者，中大新傳學院教授李立峯(Francis)開始作供。

由於辯方兩位專家的姓氏同為「李」，「雙李」容易引起混淆。甫坐下，高個子的李立峯教授說，他想用Eliza稱呼李詠怡教授，獲法庭接納。

李立峯解釋，Eliza專長政治學，故對政治選舉及相關理論熟悉。而Francis自己則是傳播學教授，辯方劉偉聰大狀在庭上先介紹Francis， 指出他畢業於史丹福大學，博士論文研究美國9.11事件中，比較報紙讀者來信和網上論壇的言論，專研範圍為「政治傳播學」。

Francis曾出版學術著作，有講述雨傘運動與傳播關係，將出版另一本書，談及六四紀念活動的集體港人記憶現象，「我對香港近年的大型社會運動，有現代歷史脈絡的理解」。Francis亦曾於2017年成為香港法庭歷史上第一位以「民意研究專家」，為佔中九子案擔任專家證人。以往，香港法庭專家證人多為醫生及物理學家等。

三位法官表示接納Francis的專家證人身份。今天在大狀袍下穿了條子花紋西裝褲的劉偉聰大狀，溫文向法官們道謝：「I am grateful」.

Francis花了頗長時間，解釋社會科學中，量化研究（大型民調）和質化研究（焦點小組）的方法論及兩者作為理解社會現像的用途。

由於過往香港法庭甚少傳召社會科學家作專家證人，三位法官發問了很多問題。唯一男性法官陳嘉信說：「我是laymen（普通人）有這些問題」；女法官杜麗冰亦在休庭前向主問劉偉聰說笑：「對不起我們打斷了你的發問。」

休庭前，三位法官先後向Francis多次問及社科研究法的疑問。Francis越答越興起，語速快了。控方周天行說：「教授請說慢一點。」Francis說笑：「我教書時，學生經常說我說得太快。」此時法庭響起了輕鬆的笑聲。

Francis說，他們進行了的量化研究，就是於2019年從連登討論區上，以電腦程式，抽取討論區上曾提及口號相關的帖子，抽取的口號分別為「光復香港」、「時代革命」、「香港獨立」、「港獨」、「五大訴求」。由於連登上的留言量可以數以百萬計，需要由懂寫電腦程式的學者作技術上協助，他再進行統計學分析。法官們沒有太多發問。

Francis說：「看數字，以數量計，量化研究(quantitative research)就可以處理，但要看人們怎樣建構意義，那要進行質化研究，因為做簡單問卷，是不可以看到意義建構的過程。此時要靠質化研究(qualitative research)，我們做了焦點小組(focus group)。」

七個焦點小組，每個有五至八人參加，三組是包含了不同年齡性別職業的市民，四組是參與者背景相近的小組，一組是社工，一組是老師，一組是年輕人。總共有40人參加焦點小組，都是在反修例運動期間，有參與示威或同情反修例運動的人。「因為我們要看示威者在想甚麼。」

三位法官發問頗頻密，其中，陳嘉信問，焦點小組只有四十人那麼少，如何有代表性？Francis解釋，質化研究是找「意義成形的過程」，代表性則由量化研究補充：「所以我們用不同研究方法互補不足。」

法官對社會現象的理解，和社科學者明顯有差別。

陳官問道：「參加焦點小組的人，會不會心裡想一樣，答你說另一樣？好像美國選舉你問選民選誰，可能他因為尷尬告訴你一個答案，但去到票站就投另一個。」陳法官形容，這是一個「危險」(danger).

作為社會科學學者，Francis這樣回應：「我不看成一種『危險』，因為人是複雜的動物，人的腦子裡不只有『單一的真相』，面對不同人，在不同處境，會影響人如何建構意義。從社會學及人類學角度，人們會在不同處境『管理自己的形像』，我會形容為因應處境而作出的『調整』，而不是在直白地說謊」。

Francis繼續解釋，「而建構意義是一個過程，同一個人在不同時候，他的想法也有改變。像我們現在在討論『甚麼是焦點小組』，我們（他和法官們）也在集體參與意義建構的過程。」

此時，Francis引述了焦點小組裡，其中一個焦點小組參與者，對「光時」口號的理解，隨時間而出現改變。

Francis在庭上說，其中一個支持反修例運動的焦點小組參與者說：

「最初我面對『光復香港。時代革命』這口號，我說不出口。為何呢？因為我最初認為這口號與『港獨』有關，好像要推翻政府，這不是我的目的，我不支持港獨的。但隨着反修例運動發展下，我理解這個運動是關於爭取普選，關於愛好自由，公義。漸漸我可以喊出口了。這個口號好像承載了一種精神。當我去到集會現場，我喊『光時』口號時，我會覺得和其他香港人連繫起來。」

Francis解釋：「這是一個好例子，這個人最初覺得，『嘩，光時口號好激進』，但漸漸他覺得意義改變了。即使他不支持港獨，他也會嗌這口號。」

「這例子正正示範了，口號的意義建構過程，可以如此複雜，豐富，充滿餘韻(nuances).」Francis說。

Francis還引述了華盛頓大學政治學教授Lance Bennett對政治口號的見解 “Effective political themes and slogans invite people to bring their own meaning to a situation. Thus, an image is an impression anchored partly in symbolic suggestion and partly in the feelings and assumptions that people have in response to that suggestion.”

(有效的政治口號邀請人們把他們自己的意義加諸其上。所以，一個影象像個錨，作為一個符號提示人們把自己的感受及假設投射到其中。)

Francis亦說，焦點小組中發現，只有部份人認為「光時口號」與港獨有關，所以口號是開放式的。「總的來說，光時口號就是關於一些失去的東西，而人們覺得需要改變。至於失去了甚麼又如何改變，則因人而異。」

法官們亦用法律用語詢問，焦點小組裡會否有「引導性問題」（leading question），即因為主持者主動提起「港獨」而引導被訪者去提及這個答案。這顯然是法庭常關注點。

但Francis說，焦點小組做法是開放讓大家討論，「而進行焦點小組時間正好在2019年9月，那時基本上整個社會都在討論這句口號的意思，是否和港獨有關。所以在焦點小組裡不需要提示，就會自然進行討論。」

法庭場境裡，引導性問題，會是法官關注的事。

這天早上，李詠怡(Eliza)教授，繼續接受控方盤問。Eliza早前曾說過，為甚麼「光時」口號在7月21日於社會流行起來，其中一個原因是因為人們對「元朗襲擊」感到憤怒，需要一個口號去表達其情緒。

然而代表律政司的署理刑事檢控專員周天行， 則挑戰Eliza，周專員多次指，7月21日口號最初出現於白天，當時中聯辦被示威者包圍，國徽被損毁，當時中聯辦外牆上更出現「光時」口號，周專員指，「光時」口號的意義，應該與中聯辦事件有關。

控方的周專員說：「中聯辦外示威中，清楚反映拒絕中華人民共國和政府的意思，你為何不認為這些示威活動的意義，有助我們脈絡性地理解口號的意思？」周專員亦呈上了多張中聯辦被損毁的照片叫Eliza細看。

Eliza指，她和研究伙伴，曾在7.21後，嘗試從數據了解為何當天之後，光時口號的使用明顯更普遍。於是她從兩張報紙裡，點算傳媒提及過的地區，發現「元朗」字眼出現的頻率，要比「西環」、「中聯辦」及「上環」高出很多。

「媒體注意力反映公眾注意力，而焦點小組發現，7.21大家一致是關注警察暴力，而不是關注中聯辦。故此我們認為令到7.21口號普及化，元朗事件比中聯辦事件重要得多。」Eliza說。

Eliza早前指，梁天琦在造勢晚會曾引述過美國黑人民權領袖Malcolm X說「the Ballot or the Bullet」意思，Eliza認為「子彈」只是比喻，並非像控方專家劉教授所說有「武器」的意思。控方更指控梁天琦有意推翻政權。Eliza當時更說，以她所知， Malcolm X不是「分裂國家主張者」(secessionist)。

周專員今日呈上Malcolm X的1964年的演講，讀出部份內容，又追問Eliza知否Malcolm X被指為 “separatist”和知否Malcolm X曾經加入激進伊斯蘭組織。

Eliza語氣有點難以置信地反問：「我們是否要進入複雜的美國種族歷史？美國黑人民族主義(black nationalist)和非洲裔美國人那時的分離主義（separatism）, 尤其是於種族隔離(apartheid)的過去有多複雜?要研讀多少歷史脈絡？」

周堅持追問：「那Malcolm X是不是分離主義者？」

Eliza沒好氣答: 「若是說建立一個有主權的國家這個理解下，我認為不是。」

周專員仍在要求Eliza看Malcolm X說話節錄。此時，彭官要求暫停提問，三位法官退後座椅商議一會，然後彭寶琴說，Malcolm X是否分離主義者，與本案案情「拉扯得太遠」（far far removed）, 彭官提醒周專員，Eliza一直不反對梁天琦在選舉演說中對港獨持正面看法。

周專員另一處的追問，把梁天琦與Eliza拉得更近，問答更有火花。周專員引述去年夏天來自《眾新聞》的報導，報導中訪問了三位學者，表達學者們對泛民立法會議員在政府表示因疫情把選舉延期一年後，是否應該總辭。

報導中，Eliza認為議員應該留任，訪問中提到議會是重要「抗爭陣地」「在威權政治下，策略上考慮比民主原則更重要……」周專員反問，梁天琦進入議會，會否也像她所說的一樣，「具策略意義，目的是去推翻政權」？

Eliza罕見地光火起來：「你在引述我？你是否在說我和梁天琦是一伙？說我和他是同黨？(You suggest I am part of his cohort?)……好了，現在我被審訊，我要回答吧？ (I am the person on trial, I have to answer this……)」辯方劉大狀立即站起來抗議，指Eliza是來做證人的。

此時彭寶琴語氣溫和地望着Eliza說：「不是的，妳是來作供，提供專家意見給法庭。請不要覺得來被審判，這不是原來的意思。」彭官打圓場道：「我想周先生要想問妳，會不會梁天琦進入立法會，覺得策略上可以作出改變，而不是留在結構以外。」

Eliza鬆了一口氣，望着彭官說了幾聲：「感謝妳的澄清，感謝。」然後Eliza詳細解釋，她在泛民總辭上的看法，已經算是「溫和派」，因為當時社會上較激進的想法，是主張泛民議員一起總辭以表示對選舉延期的不滿。而Eliza說，我主張泛民留任，是希望有議員監察政府，希望加強政府問責性。

現在仍身陷囹圄的梁天琦，始終成為庭上反覆被斟酌的客體。

Eliza今日完成作供前，有機會詳細解釋，她作為政治學者，如何理解梁天琦為何要使用「光時」口號。Eliza解釋，2016年梁天琦參加的是新界東補選，和以往立法會選舉不同，選舉制度是「單議席單票制」，並非「比例代表制」。

「比例代表制」之下，勝選者需要的票數不需很多，只拿取選票一成也可以拿到席位。然而補選的規則，則是誰多選票誰便勝出，故要爭取選票數量。

Eliza說，回看2016新東補選中，參選者多達6人，當中梁天琦的對手，有知名度高的政黨領袖，梁天琦當時相比之下，是一個無人認識的小伙子，只有大學宿生會經驗，或參加過一些小型社會運動，但知名度不高。「他需要設計一個非常搶耳的口號，以拿得最多的票數。」

Eliza指，一個知名度不夠的參選者，設計口號會有「不成比例地戲劇化」的情況(dramatizing out of proportion)，故此梁天琦即使說「選票就是子彈」是一種誇張的說法而已。

Eliza進一步指出：「很多提倡港獨的政治組織，大部份沒有具體的行動計劃，只是口說『香港獨立』」。法官彭寶琴補充：「妳所說的沒有具體行動計劃，是在公眾知道的情況下沒有而已。」

Eliza再補充：「究竟（這些組織主張的）是和平遊說，還是使用暴力或武裝力量？沒有看到這些（資訊）。」

今次被告唐英傑的電單車上，插着旗幟的版本，除了有「光時」這個八字中文口號，亦有七字英文“Liberate Hong Kong, Revolution of our Times”，中英文版本均在法庭反覆被檢驗。辯方學者卻說，原來口號的出現，並非有明確的設計時刻，或單一設計者。

彭官曾詢問，英語口號如何出現， “Liberate Hong Kong, Revolution of our Times”那裡來？彭官留意到梁天琦2016年造勢晚的佈景板已出現這七個英文字。

但Eliza指出，她曾經從梁天琦遞交給選管會的個人簡介中，找到「光時」的英文版，卻是被譯成「Ignite Revolution to Reclaim Our Age.」對於造勢晚會和選管會的文宣為何有差異，Eliza說她不知道。

而Eliza亦曾找遍不同資料，去嘗試看看梁天琦當初創作「光時」口號的原意，但發現他除了在晚會說過，口號不想專注「世代」差別，除此之外，她沒找到更多解釋。不過Eliza說，原來梁天琦最初創作了另一個八字口號，但她認為，梁天琦最初的口號不搶耳，不令人留下深刻印像。

「選舉口號要搶耳，要令人容易記起這個參選人，而原來梁天琦最初設計的口號很悶蛋，孩子氣得像大學活動口號一樣。」

原來，於社會掀起沸沸揚揚的談論，在2019年反修例運動中被廣泛流傳過，今天被法庭研究是否違反國安法的八個字口號，並不是梁天琦最初的構思。

此時，Eliza翻查文件找到了紀錄，並以廣東話在高等法院朗讀出，梁天琦最初曾經構思，但最後放棄了的意念。這個被埋葬了的口號，原來一樣是八個大字：「知行合一，世代革新」。

如果歷史有如果，假若「光時」沒有出現過，今日香港的光景又會如何？

＊＊＊
國安法首審專家證人系列（六之一）：［Regime & Redeem］
7月2日控方專家劉智鵬作供
https://www.facebook.com/wwviviantam/photos/a.1435553239866430/4210137115741348/

國安法首審專家證人系列（六之二）：［Just Do it］
7月9日辯方專家李詠怡作供
https://www.facebook.com/wwviviantam/photos/a.1435553239866430/4229321820489544/

國安法首審專家證人系列（六之三）：［過去與未來］
7月12日辯方專家李詠怡作供
https://www.facebook.com/wwviviantam/photos/a.1435553239866430/4237523026336090/

國安法首審專家證人系列（六之四）：［知行合一］
7月13日辯方專家李詠怡及李立峯作供
https://www.facebook.com/wwviviantam/photos/a.1435553239866430/4240215429400183/

國安法首審專家證人系列（六之五）：［沒有誰比誰高貴］
7月14日辯方專家李立峯作供
https://www.facebook.com/wwviviantam/photos/a.1435553239866430/4243328702422189/

國安法首審專家證人系列（六之六）：［選櫻桃的人］
7月15日辯方專家李立峯作供
https://www.facebook.com/wwviviantam/photos/a.1435553239866430/4245860505502342/

（圖為辯方第二位專家證人，中大新傳學院教授李立峯離開高院，明天他會繼續作供）

📜 [專欄新文章] [ZKP 讀書會] Trust Token Browser API
✍️ Yuren Ju
📥 歡迎投稿： https://medium.com/taipei-ethereum-meetup #徵技術分享文 #使用心得 #教學文 #medium

Trust Token API 是一個正在標準化的瀏覽器 API，主要的目的是在保護隱私的前提下提供跨站授權 (Cross-domain authorization) 的功能，以前如果需要跨站追蹤或授權通常都使用有隱私疑慮的 Cookies 機制，而 Trust Token 則是希望在保護隱私的前提下完成相同的功能。

會在 ZKP (Zero-knowledge proof) 讀書會研究 Trust Token 主要是這個 API 採用了零知識證明來保護隱私，這也是這次讀書會中少見跟區塊鏈無關的零知識證明應用。

問題

大家應該都有點了一個產品的網頁後，很快的就在 Facebook 或是 Google 上面看到相關的廣告。但是產品網頁並不是在 Facebook 上面，他怎麼會知道我看了這個產品的頁面？

通常這都是透過 Cookie 來做跨網站追蹤來記錄你在網路上的瀏覽行為。以 Facebook 為例。

當使用者登入 Facebook 之後，Facebook 會透過 Cookie 放一段識別碼在瀏覽器裡面，當使用者造訪了有安裝 Facebook SDK 來提供「讚」功能的網頁時，瀏覽器在載入 SDK 時會再度夾帶這個識別碼，此時 Facebook 就會知道你造訪了特定的網頁並且記錄下來了。如此一來再搭配其他不同管道的追蹤方式，Facebook 就可以建構出特定使用者在網路上瀏覽的軌跡，從你的瀏覽紀錄推敲喜好，餵給你 Facebook 最想給你看的廣告了。

不過跨站追蹤也不是只能用在廣告這樣的應用上，像是 CDN (Content Delivery Network) 也是一個應用場景。CDN 服務 Cloudflare 提供服務的同時會利用 Captcha 先來確定進入網站的是不是真人或是機器人。而他希望使用者如果是真人時下次造訪同時也是採用 Cloudflare 服務的網站不要再跳出 Captcha 驗證訊息。

雖然 Cloudflare 也需要跨站驗證的功能來完成他們的服務，但是相較於 Google 或 Facebook 來說他們是比較沒那麼想知道使用者的隱私。有沒有什麼辦法可以保護使用者隱私的狀況下還能完成跨站驗證呢？

這就是今天要講的新 API: Trust Token。

Trust Token API - The Chromium Projects

Trust Token / Privacy Pass 簡介

Trust Token 其實是由 Privacy Pass 延伸而來。Privacy Pass 就是由 Cloudflare 所開發的實驗性瀏覽器延伸套件實作一個驗證機制，可以在不透漏過多使用者隱私的前提下實作跨站驗證。而 Trust Token 則是標準化的 Privacy Pass，所以兩個運作機制類似，但是實作方式稍有不同。

先看一下 Privacy Pass 是如何使用。因為這是實驗性的瀏覽器延伸套件所以看起來有點陽春，不過大致上還是可以了解整個概念。

以 hCaptcha 跟 Cloudflare 的應用為例，使用者第一次進到由 Cloudflare 提供服務的網站時，網站會跳出一些人類才可以解答的問題比如說「挑出以下是汽車的圖片」。

當使用者答對問題後，Cloudflare 會回傳若干組 blind token，這些 blind token 還會需要經過 unblind 後才會變成真正可以使用的 token，這個過程為 issue token。如上圖所示假設使用者這次驗證拿到了 30 個 token，在每次造訪由 Cloudflare 服務的網站時就會用掉一個 token，這個步驟稱為 redeem token。

但這個機制最重要的地方在於 Cloudflare 並無法把 issue token 跟 redeem token 這兩個階段的使用者連結在一起，也就是說如果 Alice, Bob 跟 Chris 都曾經通過 Captcha 測試並且獲得了 Token，但是在後續瀏覽不同網站時把 token 兌換掉時，Clouldflare 並無法區分哪個 token 是來自 Bob，哪個 token 是來自 Alice，但是只要持有這種 token 就代表持有者已經通過了 Captcha 的挑戰證明為真人。

但這樣的機制要怎麼完成呢？以下我們會透過多個步驟的例子來解釋如何達成這個目的。不過在那之前我們要先講一下 Privacy Pass 所用到的零知識證明。

零知識證明 (Zero-knowledge proof)

零知識證明是一種方法在不揭露某個祕密的狀態下，證明他自己知道那個秘密。

Rahil Arora 在 stackexchange 上寫的比喻我覺得是相對好理解的，下面簡單的翻譯一下：

假設 Alice 有超能力可以幾秒內算出樹木上面有幾片樹葉，如何在不告訴 Bob 超能力是怎麼運作並且也不告訴 Bob 有多少片葉子的狀況下證明 Alice 有超能力？我們可以設計一個流程來證明這件事情。

Alice 先把眼睛閉起來，請 Bob 選擇拿掉樹上的一片葉子或不拿掉。當 Alice 睜開眼睛的時候，告訴 Bob 他有沒有拿掉葉子。如果一次正確的話確實有可能是 Alice 幸運猜到，但是如果這個過程連續很多次時 Alice 真的擁有數葉子的超能力的機率就愈來愈高。

而零知識證明的原理大致上就是這樣，你可以用一個流程來證明你知道某個秘密，即使你不真的揭露這個秘密到底是什麼，以上面的例子來說，這個秘密就是超能力運作的方式。

以上就是零知識證明的概念，不過要完成零知識證明有很多各式各樣的方式，今天我們要介紹的是 Trust Token 所使用的零知識證明：DLEQ。

DLEQ (Discrete Logarithm Equivalence Proof)

說明一下以下如果小寫的變數如 c, s 都是純量 (Scalar)，如果是大寫如 G, H則是橢圓曲線上面的點 (Point)，如果是 vG 則一樣是點，計算方式則是 G 連續相加 v 次，這跟一般的乘法不同，有興趣可以程式前沿的《橢圓曲線加密演算法》一文解釋得比較詳細。

DLEQ 有一個前提，在系統中的所有人都知道公開的 G 跟 H 兩個點，此時以下等式會成立：

假設 Peggy 擁有一個秘密 s 要向 Victor 證明他知道 s 為何，並且在這個過程中不揭露 s 真正的數值，此時 Victor 可以產生一個隨機數 c 傳送給 Peggy，而 Peggy 則會再產生一個隨機數 v 並且產生 r，並且附上 vG, vH, sG, sH：

r = v - cs

所以 Victor 會得到 r, sG, sH, vG, vH 再加上他已經知道的 G, H。這個時候如果 Victor 計算出以下兩個等式就代表 Peggy 知道 s 的真正數值：

vG = rG + c(sG)vH = rH + c(sH)

我們舉第二個等式作為例子化簡：

vH = rH + c(sH) // 把 r 展開成 v - csvH = (v - cs)H + c(sH) // (v - cs)H 展開成 vH - csHvH = vH - c(sH) + c(sH) // 正負 c(sH) 消掉vH = vH

這樣只有 Peggy 知道 s 的狀況下才能給出 r，所以這樣就可以證明 Peggy 確實知道 s。

從簡易到實際的情境

Privacy Pass 網站上透過了循序漸進的七種情境從最簡單的假設到最後面實際使用的情境來講解整個機制是怎麼運作的。本文也用相同的方式來解釋各種情境，不過前面的例子就會相對比較天真一點，就請大家一步步的往下看。

基本上整個過程是透過一種叫做 Blind Signature 的方式搭配上零知識證明完成的，以下參與的角色分為 Client 與 Server，並且都會有兩個階段 issue 與 redeem token。

Scenario 1

如果我們要設計一個這樣可以兌換 token 來確認身分的系統，其中有一個方法是透過橢圓曲線 (elliptic curve) 完成。Client 挑選一個在橢圓曲線上的點 T 並且傳送給 Server，Server 收到後透過一個只有 Server 知道的純量 (scalar) s 對 T 運算後得到 sT 並且回傳給 Client，這個產生 sT 的過程稱為 Sign Point，不過實際上運作的原理就是橢圓曲線上的連續加法運算。

SignPoint(T, s) => sT

等到 Client 需要兌換時只要把 T 跟 sT 給 Server，Server 可以收到 T 的時候再 Sign Point 一次看看是不是 sT 就知道是否曾經 issue 過這個 token。

Issue

以下的範例，左邊都是 Client, 右邊都是 Server。 -> 代表 Client 發送給 Server，反之亦然。

// Client 發送 T 給 Server, 然後得到 sT

T -> <- sT

Redeem

// Client 要 redeem token 時，傳出 T 與 sT

T, sT ->

問題：Linkability

因為 Server 在 issue 的時候已經知道了 T，所以基本上 Server 可以透過這項資訊可以把 issue 階段跟 redeem 階段的人連結起來進而知道 Client 的行為。

Scenario 2

要解決上面的問題，其中一個方法是透過 Blind Signature 達成。Client 不送出 T，而是先透過 BlindPoint 的方式產生 bT 跟 b，接下來再送給 Server bT。Server 收到 bT 之後，同樣的透過 Sign Point 的方式產生結果，不一樣的地方是情境 1 是用 T，而這邊則用 bT 來作 Sign Point，所以得出來的結果是 s(bT)。

Client:BlindPoint(T) => (bT, b)

Server:SignPoint(bT, s) => sbT

而 Blind Signature 跟 Sign Point 具備了交換律的特性，所以得到 s(bT) 後可以透過原本 Client 已知的 b 進行 Unblind：

UnblindPoint(sbT, b) => sT

這樣一來在 Redeem 的時候就可以送出 T, sT 給 Server 了，而且透過 SignPoint(T, s) 得出結果 sT’ 如果符合 Client 傳來的 sT 就代表確實 Server 曾經簽過這個被 blind 的點，同時因為 T 從來都沒有送到 Server 過，所以 Server 也無法將 issue 與 redeem 階段的 Client 連結在一起。

Issue

bT -> <- s(bT)

Redeem

T, sT ->

問題：Malleability

以上的流程其實也有另外一個大問題，因為有交換律的關係，當 Client 透過一個任意值 a 放入 BlindPoint 時產生的 a(sT) 就會等於 s(aT)：

BlindPoint(sT) => a(sT), a// a(sT) === s(aT)

此時如果將 aT 跟 s(aT) 送給 Server Redeem，此時因為

SignPoint(aT, s) => s(aT)

所以就可以兌換了，這樣造成 Client 可以無限地用任意數值兌換 token。

Scenario 3

這次我們讓 Client 先選擇一個純數 t，並且透過一種單向的 hash 方式來產生一個在橢圓曲線上的點 T，並且在 redeem 階段時原本是送出 T, sT 改成送出 t, sT。

因為 redeem 要送出的是 t，上個情境時透過任意數 a 來產生 s(aT) 的方法就沒辦法用了，因為 t 跟 sT 兩個參數之間並不是單純的再透過一次 BlindPoint() 就可以得到，所以就沒辦法無限兌換了。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, sT ->

問題：Redemption hijacking

在這個例子裏面，Client 其實是沒有必要傳送 sT 的，因為 Server 僅需要 t 就可以計算出 sT，額外傳送 sT 可能會導致潛在的 Redemption hijacking 問題，如果在不安全的通道上傳輸 t, sT 就有可能這個 redemption 被劫持作為其他的用途。

不過在網站上沒講出實際上要怎麼利用這個問題，但是少傳一個可以計算出來的資料總是好的。Client 只要證明他知道 sT 就好，而這可以透過 HMAC (Hash-based Message Authentication Code) 達成。

Scenario 4

步驟跟前面都一樣，唯一不一樣的地方是 redeem 的時候原本是傳 t, sT，現在則改傳 t, M, HMAC(sT, M)，如果再介紹 HMAC 篇幅會太大，這邊就不解釋了，但可以是作是一個標準的 salt 方式讓 Hash 出來的結果不容易受到暴力破解。

這樣的特性在這個情境用很適合，因為 Server 透過 t 就可以計算出 sT，透過公開傳遞的 M 可以輕易地驗證 client 端是否持有 sT。

Issue

T = Hash(t) bT -> <- sbT

Redeem

t, M, HMAC(sT, M) ->

問題：Tagging

這邊的問題在於 Server 可以在 issue 階段的時候用不一樣的 s1, s2, s3 等來發出不一樣的 sT’，這樣 Server 在 Redeem 階段就可以得知 client 是哪一個 s。所以 Server 需要證明自己每次都用同樣的 s 同時又不透漏 s 這個純亮。

要解決這個問題就需要用到前面我們講解的零知識證明 DLEQ 了。

Scenario 5

前面的 DLEQ 講解有提到，如果有 Peggy 有一個 s 秘密純量，我們可以透過 DLEQ 來證明 Peggy 知道 s，但是又不透漏 s 真正的數值，而在 Privacy Pass 的機制裡面，Server 需要證明自己每次都用 s，但是卻又不用揭露真正的數值。

在 Issue 階段 Client 做的事情還是一樣傳 bT 給 Server 端，但 Server 端的回應就不一樣了，這次 Server 會回傳 sbT 與一個 DLEQ 證明，證明自己正在用同一個 s。

首先根據 DLEQ 的假設，Server 會需要先公開一組 G, H 給所有的 Client。而在 Privacy Pass 的實作中則是公開了 G 給所有 Client，而 H 則改用 bT 代替。

回傳的時候 Server 要證明自己仍然使用同一個 s 發出 token，所以附上了一個 DLEQ 的證明 r = v - cs，Client 只要算出以下算式相等就可證明 Server 仍然用同一個 s (記住了 H 已經改用 bT 代替，此時 client 也有 sbT 也就是 sH)：

vH = rH + c(sH) // H 換成 bTvbT = rbT + c(sbT) // 把 r 展開成 v - csvbT = (v - cs)bT + c(sbT) // (v - cs)bT 展開成 vbT - csbTvbT = vbT - c(sbT) + c(sbT) // 正負 c(sbT) 消掉vbT = vbT

這樣就可以證明 Server 依然用同一個 s。

Issue

T = Hash(t) bT -> <- sbT, DLEQ(bT:sbT == G:sG)

Redeem

t, M, HMAC(sT, M) ->

問題：only one redemption per issuance

到這邊基本上 Privacy Pass 的原理已經解釋得差不多了，不過這邊有個問題是一次只發一個 token 太少，應該要一次可以發多個 token。這邊我要跳過源文中提到的 Scenario 6 解釋最後的結果。

Scenario 7

由於一次僅產生一個 redeem token 太沒效率了，如果同時發很多次，每次都產生一個 proof 也不是非常有效率，而 DLEQ 有一個延伸的用法 “batch” 可以一次產生多個 token, 並且只有使用一個 Proof 就可以驗證所有 token 是否合法，這樣就可以大大的降低頻寬需求。

不過這邊我們就不贅述 Batch DLEQ 的原理了，文末我會提及一些比較有用的連結跟確切的源碼片段讓有興趣的人可以更快速的追蹤到源碼片段。

Issue

T1 = Hash(t1) T2 = Hash(t2)T3 = Hash(t3)b1T1 ->b2T2 ->b3T3 -> c1,c2,c3 = H(G,sG,b1T1,b2T2,b3T3,s(b1T1),s(b2T2),s(b3T3)) <- sb1T1 <- sb2T2 <- sb3T3 <- DLEQ(c1b1T1+c2b2T2+c3b3T3:s(c1b1T1+c2b2T2+c3b3T3) == G: sG)

Redeem

t1, M, HMAC(sT1, M) ->

結論

Privacy Token / Trust Token API 透過零知識證明的方式來建立了一個不需要透漏太多隱私也可以達成跟 cookie 相同效果的驗證方式，期待可以改變目前許多廣告巨頭透過 cookie 過分的追蹤使用者隱私的作法。

不過我在 Trust Token API Explainer 裡面看到這個協議裡面的延伸作法還可以夾帶 Metadata 進去，而協議制定的過程中其實廣告龍頭 Google 也參與其中，希望這份協議還是可以保持中立，盡可能地讓最後版本可以有效的在保護隱私的情況下完成 Cross-domain authorization 的功能。

參考資料

IETF Privacy Pass docs

Privacy Pass: The Protocol

Privacy Pass: Architectural Framework

Privacy Pass: HTTP API

Cloudflare

Supporting the latest version of the Privacy Pass Protocol (cloudflare.com)

Chinese: Cloudflare支持最新的Privacy Pass扩展_推动协议标准化

Other

Privacy Pass official website

Getting started with Trust Tokens (web.dev)

WICG Trust Token API Explainer

Non-interactive zero-knowledge (NIZK) proofs for the equality (EQ) of discrete logarithms (DL) (asecuritysite.com) 這個網站非常實用，列了很多零知識證明的源碼參考，但可惜的是 DLEQ 這個演算法講解有錯，讓我在理解演算法的時候撞牆很久。所以使用的時候請多加小心，源碼應該是可以參考的，解釋的話需要斟酌一下。

關鍵源碼

這邊我貼幾段覺得很有用的源碼。

privacy pass 提供的伺服器端產生 Proof 的源碼

privacy pass 提供的瀏覽器端產生 BlindPoint 的源碼

github dedis/kyber 產生 Proof 的源碼

[ZKP 讀書會] Trust Token Browser API was originally published in Taipei Ethereum Meetup on Medium, where people are continuing the conversation by highlighting and responding to this story.

👏 歡迎轉載分享鼓掌

什麼叫做「點線面的學習」？
點，就是我們所背的單字。
線，就是幾個單字搭配起來變成一句話。
面，就是好多句話搭配起來變成一個主題、一個有意義的段落。
大多學習者都把專注度放在增加「點」的數量上，
但卻忘了最重要的是有沒有辦法連成線、和面，
就變成單字背了一堆，但一句話也講不出來。
是不是！是的人請留言！

我也有這方面的困擾（誰沒有啊～）
所以我的訓練方法『之一』就是拿這種有很多有中英對照的情境對話的書，
遮住英文的部分，直接看中文，融入情境後用我自己的話把英文講出來。
大多數時候都會跟書本寫的內容不同，
因為同樣意思本來就有很多種不同的講法呀！
這樣子的練習，同時可以翻攪一下自己腦海裡的單字庫、磨練拼湊句子的能力，
同時也可以複習甚至學到更好更口語的說法，
很多時候大家不是單字不夠多，而是不是知道這個字也可以這樣用。
我個人總是滿自得其樂的啦，常常可以自我糾正很多不好的講法。
對了，特別注意一點，『看中文講英文』不是要大家生硬的中翻英喔！
而是用你會的語言了解這個情境後，盡量跳脫中文字，用英文單字的搭配用法去想英文喔！

比如說redeem有很多種意思，
但也要知道redeem something for something else會有種『把什麼兌換成什麼』的意思，
記得時候一定要知道搭配的方式唷！

舉這本書裡其中一個小段落，大家也來試試看吧～
<信用卡紅利點數折抵>
A: 哈囉。我能用信用卡的紅利點數換成免費飯店住宿嗎？
B: 不行，但你能將紅利點數兌換成禮券或是商品。
A: 那樣的話，我想將點數換成商品。
B: 好的，請到這邊的櫥窗挑選三千元以下的商品。

大家也來試一試吧！