下載白皮書可在公衆號對話框回覆【隱私保護】
2020年3月4日，《隱私保護週三見》正式與大家見面。欄目圍繞即時可用場景式隱私保護高效解決方案WeDPR的核心技術點，每週三晚8點，以社羣直播的形式，和各位專家一起探尋隱私保護的發展之道。
每一個論題，交流羣裏的夥伴或積極參與討論，或對分享內容不吝指正，不斷助力論題拓寬研究深度，也讓我們獲益匪淺。本合集對交流羣中的精彩碰撞進行整理彙編，以饗讀者。
自下一論（第15論）起，我們將針對數字化業務系統中無處不在的數字簽名開展系列解析，歡迎更多夥伴加入，共話隱私保護。進羣請在公衆號對話框回覆【小助手】。
點擊回顧：第1~9論精彩50問
點擊圖片可跳轉閱讀文章（下同）
51
@中·李
PKCS#7中，隱私數據本身以05結尾，沒有影響嗎？
@廖飛強
不影響。不管以什麼內容結尾，都會填充，因此最後一部分是填充數據，可以區分是填充格式的內容還是數據本身的內容。
52
@Suki
數據編解碼與數據加解密有什麼區別？
@廖飛強
單純的數據編解碼不能提供數據機密性功能，數據加解密是一類提供數據機密性保護的密碼算法，但實現這些密碼算法離不開數據編解碼的參與。
另外，數據編解碼不只用在數據加解算法中，例如第9論中的單向哈希實現，也需要數據編解碼。數據編解碼是密碼協議中數據處理不可缺少的環節。
53
@blackflower
抗量子數據加密算法中，是如何進行數據映射的，需不需要用到量子協議？
@廖飛強
抗量子數據加密算法目前研究較多的是格密碼，其實現與量子協議沒關係，也不存在使用量子協議進行編解碼。類似還有NTRU等，其數據映射還是採用經典的數學編解碼方式。
54
@wheat
加解密性能看起來和數據分組方式有很大關係啊，現在國密性能普遍偏低，是否與這有關係？
@廖飛強
關係不太大，國密也是採用這些標準的分組加密模式，慢的原因主要還是在算法軟件工程實現上。
55
@wheat
分享中說到，數據分組會影響安全和性能，是不是有最佳推薦方式或者標準規範呢？
@廖飛強
一般從安全和性能上考慮，推薦CTR分組加密模式。
GMSSL中關於國密SM4的實現現狀可以參考下圖：
56
@唐煒
CTR主要還是因爲可以並行，速度快，能否結合ECB這類方式，增加一些保護的強度？
@廖飛強
CTR實際上可以看成是解決了ECB模式的安全性的優化版本，而不犧牲並行加解密。
@唐煒
CTR的密碼本會不會有點簡單啊？
@廖飛強
不會。CTR簡潔且安全，得益於它的計數器設計。每次加密解其計數器中的nonce是隨機選取的，作用類似於CBC中的IV，因此有效解決了ECB的安全問題。
@唐煒
這樣的確安全一些。IV的傳遞和使用安全性也是個管控點嗎？
@廖飛強
get到點了，IV和nonce都要隨機產生，不能重複使用。
@唐煒
要把IV當成密鑰一樣傳遞、使用 。不用了，銷燬。這樣應該可以吧？
@廖飛強
一次使用過程中，IV是附加在密文一起的，解密需要用到IV。IV的作用是提供隨機性，即相同明文、相同密鑰，每次提供不同的IV，其密文是不同的。其密文的安全，依賴於密鑰的保護。
@唐煒
但保密傳輸他不香嗎？
@廖飛強
密文+IV就是能保密傳輸的數據。
@唐煒
每次使用一個隨機的 IV和多個IV，n個參數一起產生IV，n 至少一個。不固定。安全性和便利性有啥變化嗎？也就是隨機種子的產生方式問題。
@廖飛強
建議最好不用自己設計的隨機數產生方法，容易出現漏洞，難以提供隨機性。使用標準的僞隨機生成器就能滿足要求。
57
@唐
國密算法通過加密機主要起到什麼作用？硬加密相比軟加密有哪些好處？
@廖飛強
加密機提供保護密鑰、執行加解密等密碼算法的功能。硬加密對比軟加密的顯著優勢是大幅提升了性能和安全性。另外還提供了更好的隨機數，便於產生更安全的密鑰。
58
@唐
現在的數字信封方式動態產生密鑰文件主要作用是避免密鑰泄露嗎？
@廖飛強
動態產生密鑰文件更安全，如果能一次一密，當然更好。
@劉雪峯@西電
嘉賓今天講的加密上工程面臨的問題，很透徹。隱私計算領域，工程坑也有很多，比如負數、浮點數、無理數等等，目前還沒有統一標準。這個可能也是未來學術工程化一個待解決的問題。
@廖飛強
是的，密碼協議的標準工程實現也面臨很大的挑戰，需要不斷完善、升級。
59
@邱震堯
使用支持加法同態特性的加密算法，是否也能實現類似Pedersen承諾的密文加法約束關係驗證的效果？例如使用Paillier加法同態加密算法。
@廖飛強
Paillier加法同態加密算法可以達到這種密文關係效果，但Paillier可以解密密文，主要用於用戶自身的加解密數據。其密鑰需要自己保存，因此不方便其他人驗證。
60
@唐煒
這個不解密計算的方法，已經有和應用系統貫通的場景使用了嗎？
@廖飛強
目前使用最廣泛的就是隱私支付了，比如WeDPR提供公開可驗證密文賬本方案中的隱私交易特性就採用了Pedersen承諾。
61
@H
聽過3D零知識證明，不知道是不是也用到了Pedersen承諾？
@廖飛強
通過查看公開的專利，使用到了Pedersen承諾。其核心是Pedersen承諾結合雙線性對構造了一種驗證乘法關係的方案。
62
@琪
Pedersen承諾看似挺好用，用於零知識證明過程中有什麼不足或侷限嗎？
@廖飛強
有的。Pedersen承諾適合做簡單的約束關係證明，對於複雜的關係證明都需要額外構造。另外要證明承諾值滿足在一個特定範圍，需要額外的範圍證明提供支持。
@lekkoliu
zk-SNARKs零知識證明系統。還是挺期待的
@廖飛強
後續有零知識證明系統專題哈，歡迎持續關注！
63
@lekkoliu
目前同態性在應用層面哪些已經投入了產業界使用？又分別在哪些領域，性能如何？
@李昊軒
目前利用同態性構造的密碼協議非常多，比如支付、投票、競拍等等隱私保護場景均會涉及。半同態加密方案已經比較成熟，能夠滿足大多數業務的需求。全同態近些年發展也很快，在醫療領域也有了一些應用，但是正如前面所說，還面臨數據膨脹、複雜度高等問題，支持高頻次和大數據量的業務需求，還需一定的努力。
64
@lekkoliu
全同態的方案目前僅面臨性能的瓶頸了嗎？根據摩爾定律來看，是否三到五年後能夠到來呢？
@李昊軒
全同態方案目前除了性能瓶頸外，還面臨業務方理解難度大、模型複雜等問題。但是按照當前的發展勢頭，發展可期。
65
@皺皺
同態加密和安全多方計算哪個更好？
@李昊軒
同態加密被廣泛用於構造安全多方協議。同態加密本質是一種加密算法，即對數據的加密和解密。安全多方計算則是一種協議模型，即對數據進行一定處理，得到最終結果。兩者相輔相成，不具有直接可比性。
66
@皺皺
那麼同態加密、零知識證明、安全多方計算，他們都有什麼關係？
@李昊軒
可以這樣理解，同態加密可以用來實現安全多方計算，零知識證明可以用來保證安全多方計算的正確性。根據密文的同態性，可以巧妙構造一些零知識證明，從而證明這些不同密文之間的代數關係，如證明C(v1)=c(v2)+c(v3)。
67
@kentzhang
單密鑰和多密鑰同態性能差異，大到什麼程度，和密鑰個數成怎樣的比例？
@李昊軒
多密鑰全同態加密在算法複雜度上與單密鑰至少有10倍以上的差距，可以參考這篇文章 《Efficient Multi-Key Homomorphic Encryption with Packed Ciphertexts with Application to Oblivious Neural Network Inference》
68
@kentzhang
多方同態在個數有限，數據量較小(64位以下)，比如3方的情況下，還能做到體驗上基本可用、立等可取的節奏不？
@李昊軒
在大部分情況下，多密鑰同態性能都不如其他定製化的安全多方計算協議，目前多密鑰同態在工程上的實現較少，僅有的工程實現資料主要是微軟研究院針對SEAL做的擴充。
69
@ blackflower
想問一下，有沒有可以體驗的全同態開源代碼庫？
@李昊軒
這個網站總結了一些目前開源的全同態加密庫，可以參考下：
https://homomorphicencryption.org/introduction/
70
@suki
密文同態技術和區塊鏈有什麼好的結合點？
@李昊軒
比如在聯盟鏈中，考慮到監管需求，鏈上機構可能需要將應用中的一些隱私數據上鍊，如營收賬目、產品流量等。爲了不泄露機密，機構可以使用監管方的公鑰對這些信息進行加密，加密後，信息統計可交由代理機構完成。在這種場景下，由於需要針對密文進行計算，同態加密便可大展身手。
71
@wheat
如何看待利用承諾構造乘法同態，再結合本身承諾具備的加法同態，就叫做全同態的說法？
@李昊軒
這種說法在學術圈比較少見。全同態在密碼學中一般指全同態加密FHE，Fully Homomorphic Encryption，或者我們一般說密文具備什麼樣的同態性。
72
@wheat
snark是否有使用同態性質，或者說藉助這個特性？比如如ZCash中的拆分支付，是否用到？我理解需要證明會計平衡，可能需要……
@李昊軒
ZKSNARK是基於電路構造，原理上也是根據不同密文中對應的明文相互關聯進行驗證，這種也可以說是廣義上的同態性。
73
@wheat
既然全同態這麼難，有沒有存在比較好的辦法，將乘法轉爲加法，然後用加法同態來實現隱匿計算？聯邦學習中就必然會面臨這個問題
@李昊軒
機器學習中經常面臨的問題是計算模型不明確，如果是確定性的計算過程，比如說固定輪次的乘法這種，轉換爲加法，然後使用半同態方案就比較高效。
74
@郭銳 Kyon Guo
感謝李老師，很硬核！能否推薦同態加密相關的綜述性論文供大家參考。
@李昊軒
半同態的算法目前比較成熟，我就不再贅述了。多密鑰全同態的論文可以參考這篇《Multi-Key FHE from LWE》
75
@琪
請問門限簽名講解過程中，提到了可以不依賴可信第三方來初始化，具體是怎麼操作的？
@李昊軒
有多種替代第三方初始化的過程，我這裏拋磚引玉給大家提供一種方法。一種常見的思想就是使用我們之前提到過的密文同態性，用戶本地產生隨機數，將私鑰碎片放入密碼信封中，作爲密文共享，最後完成初始化的過程。
76
@小花
想了解一下，門限密碼學算法和相關技術方案，有沒有好的開源庫推薦？
@李昊軒
門限密碼學有很多通用算法，以門限簽名爲例，基於BLS的門限簽名就是比較常用的實現方案，開源社區上有很多成熟實現。
77
@李大狗
比多籤更加複雜的權限控制是怎麼實現的呢？例如不同的私鑰有不同的權重。
@李昊軒
有一個很樸素的思想，就是一個實體擁有兩份私鑰，這樣他對外的權重就可以理解爲2。當然，更復雜的擴充方案密碼學中也有考慮，但是如何在保證私鑰權重隱私性的情況下，還能實現不同權重的佔比，也是密碼學一個很有意思的研究方向，這裏也和安全多方可計算相關。
@唐煒
如果不考慮性能，可以切多份私鑰，權重靠私鑰的數量來劃分。以前的方案裏，門限都是用來解開備份密鑰的。
78
@wheat
門限加密只能是公私鑰的方式嗎？有沒有對稱加密模式的門限加密呢？
@李昊軒
針對祕密共享是密碼學原語之一，公鑰加密和簽名是公鑰密碼領域的設計。
79
@wheat
似乎沒提schnnor，怎麼看schnnor和BLS？
@李昊軒
schnorr聚合簽名是將n個公鑰，對應的n個簽名聚合在一起，減少驗證簽名成本的一種優良方案，和我們講的門限簽名不太一樣，這裏就沒有展開。
80
@袁浩然-Haoran Yuan
儘管現有的祕密分享、門限加密、門限簽名可以實現多用戶參與的密文解密、簽名等功能，但是現有的方案在用戶撤銷時，是否依然面臨系統重構問題，是否還是需要重構拉格朗日差值多項式？
@李昊軒
作爲一種特殊的羣簽名，可擴充的門限密碼方案在複雜度上都不是特別理想。成員新增、擴充等操作都依賴重複初始化的過程，這個也是一個很有意思的研究方向，就這個問題而言，大部分方案看上去都需要。
81
@曾毅Devin Zeng
如果要實現ABC三個用戶的三分之二門限簽名，那麼在簽名前，ABC是怎麼得到自己的私鑰分片的？他們需要兩兩通訊多次嗎？
@李昊軒
可以參考《Threshold Signatures, Multisignatures and Blind Signatures Based on the Gap-Diffie-Hellman-Group Signature Scheme》這篇文章。這篇文章基於BLS做了門限簽名的擴充，交互不需要兩兩交互，只需要所有成員共同交互一次就可以，剩下的過程可以用交互證明來省略。
82
@楊高峯
可不可以多硬件同時工作，提高可用性？
@嚴強
一定程度上是可以的，但有安全性代價和限制。
這裏關鍵是要不要把TEE中私鑰導出，如果需要導出，那解決可用性問題的同時，其安全性的賣點也相當於打了折扣。
如果不從TEE中導出私鑰，可以通過一些基於門限密碼學的方案，聯合使用多個硬件設備中的私鑰共同生成一個公開公鑰，這樣可在一定程度上緩解可用性問題，但是這些方案，一般只支持靜態的TEE設備組，不支持動態增加TEE設備，不能從根本上解決可用性問題。
83
@達達
我覺得評價一個技術的成熟度，不應該看存在了多少年，應該看實用了多少年吧~
@李昊軒
評價技術成熟度可以從學術研究和產業落地兩方面考量，學術價值和產業應用不完全對等，但兩者相輔相成。
@嚴強
有道理，在這個標準上，那TEE可能就更年輕了。
84
@suki
想請問下嚴博士，有人說TEE是隱私保護對於數據可用性的妥協，不得不信廠商和平臺，怎麼看待這一觀點？
@嚴強
用戶總是有選擇的權力的。隱私保護的訴求很多時候是一個風險管理問題，如果收益很高，用戶對隱私風險也不敏感，那信廠商和平臺也無妨。但如果不是這個情況，可以酌情選擇不參與，壓根不提供數據，或者使用其他技術方案。
也會有一些觀點提到，其他的軟件通用方案都不能支持現有的實際業務需求，說的也不是沒有道理。 但是它並沒有提定製化方案也走不通，我們在實際業務探索中發現，如果認真去提煉具體的業務場景需求，並圍繞場景的共性爲核心，設計定製化方案，也能很好滿足需求，而且不需要引入任何中心化的可信第三方。
85
@三塔菌
感謝嚴博士的精彩分享，作爲小白，想請教幾個問題：
1、 TEE是和硬件(或者硬件平臺)強相關的，目前可以作爲平臺服務商的公司是否屈指可數呢？那麼，基於TEE的數據隱私方案是否只能這些廠商來主導呢？
2、 TEE技術在保護用戶數據方面有很好的優勢，但是這種能力是否適用在物聯網場景下呢？
3、 聽說有軟TEE和硬TEE兩種，軟TEE是否是一種僞TEE呢？
@嚴強
1、 TEE只是一個技術工具，很難說由誰來主導的問題，作爲用戶和開發者，大家總是有，不使用平臺服務商指定的TEE權力的。
2、 對於物聯網應用，如果TEE硬件設備，是在公開環境中部署的，它可以起到一定的安全加固作用。至於是不是能夠保護好用戶數據，就要看TEE設備實際有誰來控制了。
3、 軟TEE通常指通過軟件算法手段，來覈實程序執行的環境是否被修改，通常會比硬TEE的驗證功能弱。但其也有優點，一般不依賴中心化的驗證服務，不能說是僞TEE。
86
@三塔菌
我理解TEE是一個基於硬件的可信執行環境，這個硬件在終端設備上，祕鑰不出終端設備。但是基於雲服務的TEE是指雲服務廠商提供TEE的方案麼？這個祕鑰要是不在終端，感覺就有些不靠譜了~
@嚴強
TEE的精髓在於，信則有。如果相信雲服務商，自然可以用用他們的服務。否則的話，還是需要自己能夠掌控TEE硬件。作爲一項安全加固技術，TEE在自己機構內部，還是可以安心使用的。
《隱私保護週三見》
“科技聚焦人性，隱私迴歸屬主”，這是微衆銀行區塊鏈團隊推出《隱私保護週三見》深度欄目的願景與初衷。每週三晚8點，專家團隊將透過欄目和各位一起探尋隱私保護的發展之道。
欄目內容含括以下五大模塊：關鍵概念、法律法規、理論基礎、技術剖析和案例分享，如您有好的建議或者想學習的內容，歡迎隨時提出。
欄目支持單位：零壹財經、陀螺財經、巴比特、火訊財經、火星財經、價值在線、鏈客社區、IFTNews
