Tag: to

棄用 Keybase (Zoom 買下 Keybase 的新聞)

前幾天的新聞，Zoom 的新聞稿：「Zoom Acquires Keybase and Announces Goal of Developing the Most Broadly Used Enterprise End-to-End Encryption Offering」，Keybase 的新聞稿：「Keybase joins Zoom」，看到後就把本來的服務刪一刪了...

這篇屬名由 Zoom 創辦人發出的公告，裡面多到讓人不知道怎麼吐槽的部份，我們就把唯一的粗體字拉出來討論好了：

We are excited to integrate Keybase’s team into the Zoom family to help us build end-to-end encryption that can reach current Zoom scalability.

先不講先前被戳破根本就不是 end-to-end encryption 的問題，影音上面因為 transcoding 的問題，如果要在 video stream 上做 end-to-end encryption 的話分成兩種方式可以做：

a) 一種是發送端直接產生出多個不同 bitrate 的 video stream，這種方式其他家都已經很熟悉了，缺點也很明顯，就是吃各種資源，包括發送端的壓縮能力與頻寬。

b) 另外一種方式是產生出可以疊加的 video stream，有點像是 progressive image 的方式，第一個 stream1 的畫質最低，第二個 stream2 則是「補強」第一個 stream1，這樣子可以降低資源的需求。

另外有想到 Homomorphic encryption 的方式，直接可以疊加加密後的 stream1 + stream2，不過 bitrate 應該不會降低，就算真的設計的出來應該也沒用...

如果是 a) 的方式，業界對於 key 的交換都已經解的還不錯了，但這個方式沒什麼競爭性 (因為其他家也都已經做完了)。

如果是 b) 的方式，很明顯該找的是 codec 的公司 (要做出可以疊加的 codec)，而不是搞密碼學的公司。

回到原來的問題，現有的團隊有 2500 人，裡面的技術團隊沒辦法搞定 end-to-end encryption，ok 沒關係，那現在的 CTO Brendan Ittelson 應該可以建一個團隊吧？所以我翻了一下他的 LinkedIn 看了一下他的經歷，對不起我錯了，我瞬間不知道怎麼寫下去了，我豆頁痛...

在 AWS 上用 pfSense 串接的細節

這邊講的是在 AWS 上想要串接不同帳號的流量 (也就是 site-to-site VPN)，不使用 AWS 自己提供的串接服務，而是用 pfSense 串接。

會自己搞主要有幾個考慮：

  • 考慮到 AWS Transit Gateway 的費用，每掛一個上去就要多收一次錢，另外上面處理的流量要再收費。
  • 應用的流量不大，所以用個 t2.nano 跑也有個 100Mbps 左右的 capacity，算是夠用了。
  • 而且應用在寫的時候也考慮到斷線後的處理，加上用戶端的網路本來就不怎麼穩定，AWS Transit Gateway 的 SLA 再怎麼高，我也還是得處理斷線時的後續機制，不如就不要那麼緊張...

在設定的時候要注意的事情：

  • EC2 的 Source IP/Destination IP 檢查要關掉，這算是基本盤。
  • VPC 內的 Routing 要確認過一輪。
  • EC2 上的 Security Group 對於 pfSense 的主機得全開，因為 pfSense 會丟出不屬於他自己 IP address 的封包，也會接收不屬於自己 IP address 的封包 (透過上面提到的 routing)，這些都還是會經過 Security Group 的檢查，而 Security Group 能設定的數量有限，基本上應該會全開...
  • pfSense 在設完 IPsec 後，同樣在 pfSense 上面的 firewall 需要手動加開，因為預設是關的。

其實這套作法就是在 AWS 還沒推出 Transit Gateway 前的作法，只是老方法還是很好用...

End-to-End Encryption 的標準？

看到「The Messaging Layer Security (MLS) Protocol」這個被提出來的標準，還在討論中...

簡介就說明了這個標準除了標準的 E2E 外，還設計了有效率的 Group 機制：

Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.

要設計機制的人可以拿來翻翻看...

Transport-Layer Encryption 與 End-to-End Encryption 的差異

EFF 的「Transport-Layer Encryption vs End-to-End Encryption - GIF」這篇文章介紹了 Transport-Layer Encryption 與 End-to-End Encryption 的差異，最後還給了一張 GIF 說明：

其實 GIF 給的範例還蠻清楚的，在 Transport-Layer Encryption 中服務提供商可以看到原始內容 (以 GIF 內提到的例子就是 Google)，而在 End-to-End Encryption 中就不行，只有傳輸雙方可以知道原始內容。

然後文章裡也提到了 Tor Messenger，可以吃現有的通訊軟體，然後在上面疊出 End-to-End Encryption。

Google 發表新的 TTS (Text-to-Speech) 技術 Tacotron 2

Tacotron 是 Google 發表的 TTS 技術 (i.e. 輸入文字，請電腦發音)，而前一版的 Tacotron 的錄音可以參考「Audio samples from "Tacotron: Towards End-to-End Speech Synthesis"」，論文則是在「Tacotron: Towards End-to-End Speech Synthesis」這邊可以看到。

這一版的則是在 Twitter 上看到有人提到：

這一版叫做 Tacotron 2，錄音可以參考「Audio samples from "Natural TTS Synthesis by Conditioning WaveNet on Mel Spectrogram Predictions"」，論文在「Natural TTS Synthesis by Conditioning WaveNet on Mel Spectrogram Predictions」。

這次在錄音頁面的最下面提供了盲測 (人類與 Tacotron 2 的錄音)，基本上已經分不出哪個是真人了...

在 Percona XtraDB Cluster 裡使用 async replication 時人工 failover 的方式...

在使用 Galera Cluster 時還是可以架設一般的 slave server (Percona XtraDB Cluster 則是 Percona 對 Galera Cluster 的封裝)，像是這樣的架構：

其中 node{1,2} 為 cluster，node3 則是傳統的 async replication，來源的 master 為 node1。

當 node1 掛掉時，我們沒辦法自動將 node3 的 master 從 node1 改指到 node2，因為 binlog 的位置不一定正確。

在「Changing an async slave of a PXC cluster to a new Master」則是提供如何人工用最簡單的方式介入。

主要是靠 Galera Cluster 會在 binlog 內寫入 Xid 這個值，這個值可以在 global status 內的 wsrep_last_committed 看到。因為這個值在全 cluster 都是同步的，就可以拿來人工尋找 binlog 位置後手動下 CHANGE MASTER TO，而不用 pt-table-sync 同步修老半天...

而且邏輯被整理出來以後，就有機會寫成程式自動化... 這算是一個不錯的開頭 :p