開發者會議紀錄 DevMeeting 20190505

內容概要

  • Monero 開發部分
    • 下一次發佈的版本號差不多確定是 0.14.1.0。
    • 在建立發佈分支前,正在等待 vtnerd 審查完 SSL 功能實作的 PR,該功能將會加密節點與錢包的連線。
  • GUI 錢包開發部分
    • 基本上已準備好這次的發佈了。
    • 操作介面大幅的改進、最佳化。
    • 新加入了白色系的佈景主題。
    • 對 Trezor 硬體錢包的支援已經完成了。
    • 為了解決 Qt 5.7 的一些問題與使用新功能,Qt 版本更新至 5.9.7。
    • 新增桌面彈出式通知功能, 按這裡搶先看!
    • 加入現金價顯示方式(預設為關閉)。
    • 預計在 0.15 的版本會將發送交易的介面和流程設計得更直覺,點這裡查看最新進度。
  • RandomX 開發部分
    • 程式碼已於 4/30 進入凍結階段。
    • 目前已有兩個外部審查的提案,還有第三個提案在準備中。
    • RandomX 與 monerod 的初步整合實作已經在 hyc 的 github repository 中了。
    • CPU 的最佳化還在進行中。
    • CUDA版本約已有80%完成,按這裡看目前的進度

繼續閱讀...

Monero 2018 年發展回顧

Monero在過去的一年還算是成果豐碩,也經過了不少風波。

本篇文章要來做一個2018的超濃縮懶人包,最後加上一點小編的心得與未來的看法。

歷經的風波們

  1. ASIC礦機算力在年初的大量增加

    依社群共識決定進行了數次PoW微調 預計是要撐到長期抗戰版的PoW算法(RandomX)正式上線。

    • CNv1: 2018/04 上線
    • CNv2: 2018/10 上線
    • CN-r: 2019/03 上線
    • RandomX: 等待外部審查中,預計2019/10上線
  2. 兩個有驚無險的重大漏洞: 重複計數和燒毀

    這兩個漏洞雖然是出現在錢包軟體而沒有影響到協定層面。但仍有可能造成交易所的重大損失,所幸在沒有被惡意利用的情況下順利修復 經過這兩個漏洞,專案的漏洞反應流程的制度化在檢討後也更加完善。

  3. 分叉幣(XMO,XMC)對隱私保護機制造成的傷害

    由於 Monero 的原始設計並未考量到分叉空投幣的情況,導致兩條鏈上的同一使用者經由比對環簽組合後會被找出真實的交易輸出 雖然隱匿地址和保密交易不受影響,但還是會一定程度傷害環簽的保護效果,因此開發者們加入了數個機制來保護原鏈與分叉幣的隱私 譬如在新鏈重複使用環簽組合或是避免使用有風險的交易誘餌,在後續的XMC分叉後證明這些保護機制是有效的。

    繼續閱讀...

Monero發布新版本v0.14.0更新

更新總覽

這是 Monero 軟體的 v0.14.0 發布版本。這項主要更新是因應三月九號的交易網路升級,該升級帶來了由 Cryptonight-R 發展而來的新 PoW 演算法、增加新的區塊權重(block weight)演算法、並改善了 RingCT 的格式效率。這是一個過渡性的穩定版本,特別針對交易網路升級的更新,並未包含過去六個月新增的功能性更新。那些新的功能更新將會包含在未來的0.14.1發布版本,預計將會在三月的交易網路更新後不久發布。 關於此項版本的數個重點項目:

  • 由 Cryptonight-R 發展而來的新 PoW 演算法
  • 新的區塊權重(block weight)演算法
  • 更有效率的 RingCT 格式
  • 填滿短格式的付款 ID 以達到交易資料一致性
  • 過時的長格式付款 ID 將預設為停用
  • 增加區塊速率大幅度改變或區塊鏈大量重組時的提醒
  • 無法混幣的輸出可以再被花費
  • 修復在RPC中被不當修剪的JSON內容
  • 一些關於在各平台上編譯的錯誤修復
  • 修復在關閉軟體時的錯誤

    繼續閱讀...

開發者會議紀錄 DevMeeting 20181216

  • GUI錢包的開發動態
    • 許多Pull request(皆為新程式碼)。
    • 多數是為了修復Bug、改善使用者體驗與效能提升。
    • 雖然這些多數是小小的改動,全部綜合起來效能改善的程度也是很可觀。
    • 補充一些特別的註記如下:
      • 基於日期的復原功能-使用者復原錢包時可以選擇一個錢包約略被創建的時間範圍,復原會自動取得該時間的區塊高度來還原,使用者從此不必再去猜測區塊高度了。
      • 簡易模式-(還在計畫中)建立一個更易用的使用流程,讓新使用者可以選擇使用遠端節點而不需要下載整個區塊鏈。
        • 最後目標是做成混和式的方案,當使用者還在同步區塊鏈時亦可預先透過遠端節點使用錢包。
    • 計畫在下次的主要發布中開始支援Trezor,可能會在2019年的4月左右。
    • Windows的安裝程式在等Luigi完成他的部分。
  • 核心程式碼的開發動態
    • Mooo正在處理效能改善跟修剪(Pruning)功能。
    • vtnerd實作出了一些支援Tor的整合(p2p分享與交易廣播)。

以上翻譯來自於紀錄原文: https://monerobase.com/article/monero_devmeeting_2018-12-16 完整會議紀錄:

繼續閱讀...

開發者會議紀錄 DevMeeting 20181014

  • Monero GUI 已被標記為發布版本,但在最後又多了一些需要納入的更新(其一包含了與Ledger整合相關的東西)。
  • 基於GUI較晚發布,本次開者會議幾乎都聚焦在”如何能更妥當的讓發布前期的測試者早點拿到測試版”。
    • 可重現編譯的版本被視為可顯著改善此狀況的方法。
      • 論壇資助系統(FFS)有些升級的作業正在進行

以上翻譯來自於紀錄原文: https://monerobase.com/article/monero_devmeeting_2018-10-14 完整會議紀錄:

繼續閱讀...

開發者會議紀錄 DevMeeting 20181007

  • 本週合併了許多將在v0.13.0版本發布的程式碼
    • 執行檔可望在本週發布,CLI應當會率先發布,而後才是GUI。
    • TheCharlatan將會宣布/建議本次版本使用可重現編譯(reproducible build)的可行性。
      • 若不幸失敗了,程式碼/二進位版本將會以原先的方式發布,可重現編譯的版本將改於v0.13.1推出。
    • 翻譯小組在發佈前還有些檔案需要處理。
  • 未來的版本發布規劃
    • 建構小組希望於2019一月推出v0.14.x版本 - 大幅提前於下次協定升級的時間。
    • 將會預留超過一個月的時間測試並於二月正式發布。
    • 目標是讓排程不要這麼緊迫 - 在接近正式發布的時候別塞入太多的新功能。
    • 防彈協定的安排方式是個很好的例子:原先排在2018較早的月份,但因程式碼的審查而決定延後推出,整個過程運行的相當順利。
  • v0.13.x 的GUI_可能_會加入使用手冊/教學文件
    • 如何妥善的打包還在討論中。
    • 用PDF很好但可能會成為一個攻擊向量。
    • 團隊正在尋求替代方案。
  • Mac在v0.13.x支援Ledger的測試尚未收到足夠的資料,開發Ledger整合介面的其中一名開發者,cslashm,並無Mac供測試
    • 目前已知在Mac上有個可能的bug是按下按鈕過快或過慢時會有點問題。
  • 下次開會將於10月14日 UTC 17:00(台灣時間10月15日01:00)

    繼續閱讀...

關於燒毀漏洞的事後檢討

這篇文章要來談一個被稱為燒毀(burning)的漏洞。這篇文章的目標是對上述的漏洞提供完整的細節,解釋這是如何被用來攻擊線上服務、商家與交易所,並且 Monero (開發)社群是如何處理這個漏洞。

這個漏洞基本上來自於錢包在接收到被燒毀的交易時不會發出警告。因此,有心的攻擊者可以利用這點,僅是支付網路交易就能燒毀一個服務機構的錢包內資金。經由此漏洞,攻擊者其實沒有直接的獲益,但是仍然可能有間接的獲益。燒毀的概念上是將數筆交易送至相同的隱匿性地址,而這地址是在先前就已經存在的,這概念的例子可以在先前的討論中看到。不幸的是,這問題被利用來攻擊服務機構的可能性並沒有被察覺,直到 Monero 的一位 reddit 社群成員提出了這個攻擊假設。

目前,Monero的隱匿性地址可以用這樣的公式來表示:

P = Hs(rA||i)*G + B

其中

Hs 是一個雜湊至純量的函式(注意這存量的輸出為 reduced modulo l);

r 是交易私鑰,由發送者隨機產生;

A 是查看公鑰,是收款者的錢包地址字串的其中一部分;

i 是交易輸出索引 (每筆交易輸出都有其索引編號,譬如第一筆交易輸出就是索引0);

G 是標準 Ed25519 的基點;

B 是花費公鑰,是收款者的錢包地址字串的其中一部分;

而 Monero 的金鑰映像可由以下公式表示:

I = xHp(P)

其中

x 是一個私鑰/純量(由收款者的花費私鑰與 ECDH 共享金鑰雜湊純量輸出相加而得);

Hp 是雜湊至點函式;

P 是隱匿性地址;

可以從上面的公式看到,將 Monero 發送至相同的隱匿性地址時將會輸出多個重複的金鑰映像,當區塊鏈網路中出現重複的金鑰映像時,網路將會將之捨棄,因為這相當於重複花費的攻擊。因此每一個隱匿性地址都只能有一個交易輸出被花費一次(錢包會自動挑選面額最大的來使用),而其餘的交易輸出將會無法被花費/被燒毀。此外,發送到同一個隱匿性地址的交易之間關係將可以被連結起來。

實際上來說這個漏洞可以被如下實施,攻擊者首先產生隨機的交易私鑰,接著修改程式碼使錢包只使用這份金鑰並將數筆交易都送到對方地址(如某交易所的熱錢包地址)的相同隱匿性地址,最後如果攻擊者發送了 1000 次 1 XMR 的交易到交易所,因為交易所的錢包沒有對這種異常狀況發出警告,因此交易所將會歸戶給該攻擊者 1000 XMR 的額度,接著攻擊者就可將之交易為 BTC 並提領出 BTC,最後交易所就會留下 999 筆 無法花費/被燒毀的 1 XMR 交易輸出。

這個漏洞是經由一位社群成員在 Monero reddit 社群上描述了一個可能的攻擊假設後所發現。一個祕密更新檔迅速的被製作出來並隨後在這個 pull request 中提交到原始碼中。

我與一些成員私下地盡可能通知了所有的交易所、線上服務、與商家,請他們將這更新檔應用在 v0.12.3.0 發行版上。在此重申一次,(從上一篇漏洞檢討的文章中提過)顯然這不是個最好的方法: (i)這不可避免地排除了與我們沒有聯絡管道但又是 Monero 生態中重要的對象。(ii) 這可能導致差別待遇的觀感。但是,在這段期間尚未有足夠的時間改善漏洞通報處理流程,雖然這份消息有在公開郵件列表中發送可以視為一個進步。最後我想在這邊強調,任何在 Monero 生態中的服務機構或組織都非常強烈希望可以訂閱公開的郵件列表。 總而言之,這在錢包中的一個漏洞可以讓攻擊者以最少的成本造成服務機構或組織巨大的損失。

幸好,這個漏洞沒有造成交易協定和貨幣發行量上的影響。不過我們的 Monero 是一個社群,非常需要大家關注程式碼,尤其是新提交的 pull request。如果你熟悉C或C++語言,若時間允許,即使僅是是個幫忙一小部分的審查都會對 Monero 的開發產生助益。此外,這個事件也是再一次的重要提醒,加密貨幣與其軟體都還是在發展中階段,容易出現(重大)漏洞。

本篇消息譯自核心開發團隊網站: https://getmonero.org/2018/09/25/a-post-mortum-of-the-burning-bug.html

開發者會議紀錄 DevMeeting 20180909

    • 由於與表定分叉更新的時間已非常接近(約於2018年10月18),因此下次的版號將直上V0.13.0.0而非原規劃的v0.12.4.0

    • 最新的PoW已更動為CryptoNightv2,需要一些會C++的開發者幫忙審查

    • Kovri 的程式碼已正式從GitHub移至Gitlab,而主要的Monero 程式碼尚未決定是否要移動

      • 很可能以Gitlab為主而Github作為鏡像備份

      • 也可能Monero就直接用Gitlab的軟體自行架站

      • 防彈協定(BulletProofs)與CryptoNightv2程式碼的合併並於testnet上運行預期會在9月10-11號開始

      • 下次開會時間為2018年9月16號

繼續閱讀...

關於重複計數漏洞的事後檢討

這篇文章要來談重複計數(multiple counting)的漏洞,其包括了兩個變種。這篇文章的目標是對上述的漏洞提供完整的細節,解釋這是如何被用來攻擊線上服務、商家與交易所,並且 Monero (開發)社群是如何處理這個漏洞。

重複計數漏洞的兩個變種存在於子地址(subaddress)功能中,這功能用了個不同的交易金鑰程式碼架構。第一個漏洞的變種簡單來說就是沒有對重複的公鑰進行檢查,因此攻擊者可以重複將同份交易公鑰包含在交易中,這結果導致了接收者的錢包會回報收到了x倍於其真正收到的的交易數量(x是代表收到幾次交易金鑰的一個整數),所有用來回報收到交易的指令(如show_transfers (CLI), get_transfers (RPC))都被此漏洞影響。但是餘額並沒有受到影響,錢包依舊會回報正常的資金餘額。可惜的是,大多數的交易所都是利用 get_transfers 或 get_payments RPC指令在運作,因此重複的交易公鑰將會導致計算出錯誤的金額。

不幸的是,這個漏洞的變種非常容易被使用,攻擊者可以輕易的利用在 src/cryptonote_core/cryptonote_tx_utils.cpp 中的 add_tx_pub_key_to_extra(tx, txkey_pub) 來附加重複的交易公鑰。實際上的運作如下: 攻擊者在 src/cryptonote_core/cryptonote_tx_utils.cpp 中附加了譬如三次的金鑰,因此在他的交易中就會出現四筆相同的交易公鑰。這導致了當攻擊者將一筆 1 XMR 的交易發送至目標交易所的時候,交易所很有可能就會計帳給攻擊者 4 XMR 的餘額,於是攻擊者就可以領出4 XMR的資金而惡意盜取了交易所 3 XMR 的資金。若交易所沒有進行對餘額與進出交易金額的核對或檢查熱錢包的異常狀況,那麼攻擊者基本上可以重複上述攻擊直到交易所的熱錢包被領空或更慘的是到整個交易所的資金耗盡為止。

本漏洞的第二個變種,在 HackerOne 上有完整的報告,原理是程式碼沒有對假冒的交易公鑰進行檢查。因此攻擊者可以利用變造後的交易公鑰欺騙錢包使其將交易輸出計算為實際收到的兩倍,而與第一個變種類似,錢包餘額並不會受到此漏洞影響。 本漏洞的第一個變種最早是在 GitHub 上被提出並迅速地在這份 PR 中被 moneromooo 修正。 不幸的是,這個漏洞的嚴重性被低估,直到 (i) 一個交易所的 Monero 分叉幣被利用此手法攻擊 (ii) 在 HackerOne 上的一位資安研究員(jagerman)提供了完整報告關於如何利用此漏洞竊取交易所資金。而漏洞的第二變種是由 HackerOne 上的 phiren 所提出,並也被快速的在此份PR中修正。兩份修正都已由 fluffypony 合併在 v0.12.3.0 的發布版本中。

在 v0.12.3.0 定版之後,筆者(dEBRUYNE)與其他開發者們私下地盡可能通知了所有的交易所、線上服務、與商家。但顯然這不是個最好的方法: (i)這不可避免地排除了與我們沒有聯絡管道但又是 Monero 生態中重要的對象。(ii) 這可能導致差別待遇的觀感。此外,這個漏洞消息應該要於公開地郵件列表中發布,但可惜的是並沒有,我們應要能從這樣的疏忽中記取教訓。我們是一個 Monero 的社群,應該要找出一個更順暢的資安弱點處理流程(譬如回報重要漏洞給交易所、線上服務與商家的的流程),一個只提供給交易所、線上服務與商家的”祕密”郵件列表或許符合這個概念。加上需要一些繁瑣的認證程序或許會比公開的郵件列表安全,因為聰明的攻擊者會毫不猶豫地訂閱這份郵件列表。

總而言之,在錢包中的一個重要漏洞,在初期被低估其嚴重性,導致在攻擊者得以在 Monero 生態中的竊取交易所的資金。幸好,這個漏洞僅限於影響錢包軟體中的計帳功能,而在交易協定和貨幣發行量上沒有受到影響。我們必須在此次事件中記取教訓去改進使我們在未來遇到類似漏洞時能夠阻緩其帶來的影響。此外,這個事件也是一個重要的提醒,加密貨幣與其軟體都還是在發展中階段,容易出現(重大)漏洞。因此對於提供服務的單位,盡可能納入完整性檢查是比較好的(替如檢查交易總和是否吻合真實帳戶餘額),此外,Monero 開發社群也正在研究加入這類核對功能至 RPC 錢包中的可行性。

註記: 1. 一份包含著50份相同交易公鑰的交易範例: (01ede13f013833f8aef14a9397b83fd5171833ab55bc480104dd6ba86ca8f13558) 可以在此查看這份交易內容。

本篇消息譯自核心開發團隊網站: https://getmonero.org/2018/09/05/a-post-mortum-of-the-multiple-counting-bug-2018-09-05.html

開發者會議紀錄 DevMeeting 20180826

  • 下次分叉的日期暫訂為2018年的10月18日
  • SChernykh已貼出了CrptoNight-v2最後的更動
    • 即將要合併入程式碼
    • 這將會是分叉後的新Proof of Work協定
  • 最終版的防彈協定即將要合併
    • 不確定是否會納入數個可以加速程式速度的程式碼修正
  • Endogenic 的LightWallet pull request需要幫忙審閱
  • ph4r05 提交了一些初步的程式碼來支援Trezor的硬體錢包
  • 一旦新防彈協定和CryptoNight-v2的合併入主程式碼後,testnet的區塊鏈將會重組並會需要一些測試者
    • 預計下禮拜開始,最早禮拜二。
  • GUI在分叉前可能還是會有個v0.12.4.0的更新發布
  • 讓Monero可進行重現編譯(reproducible builds)的工作持續進行中,正在徵求額外的協助
  • 下次開會時間是2018年9月9日

    繼續閱讀...