主頁 > 資料庫 > CRYPTO 2019-論文閱讀:Two-Party ECDSA from Hash Proof Systems and Efficient Instantiations(1)

CRYPTO 2019-論文閱讀:Two-Party ECDSA from Hash Proof Systems and Efficient Instantiations(1)

2020-10-06 02:00:29 資料庫

Two-Party ECDSA from Hash Proof Systems and Efficient Instantiations
譯:基于安全多方計算的兩方橢圓曲線數字簽名

  • 摘要部分
    • 引言
    • 總結


論文地址:https://eprint.iacr.org/2019/503.pdf
因為該篇文章太長,所以將分兩次進行介紹,該篇博文只介紹背景知識、結論等,核心部分推導我將會在下一篇博文中進行介紹,如果翻譯與理解有不對的地方,還請讀者大大們指摘,(部分翻譯內容也會進行增加補充)>-<

摘要部分

ECDSA is a widely adopted digital signature standard. Unfortunately, efficient distributed variants of this primitive are notoriously hard to achieve and known solutions often require expensive zero knowledge proofs to deal with malicious adversaries. For the two party case, Lindell [Lin17] recently managed to get an efficient solution which, to achieve simulation-based security, relies on an interactive, non standard, assumption on Paillier’s cryptosystem. In this paper we generalize Lindell’s solution using hash proof systems. The main advantage of our generic method is that it results in a simulation-based security proof without resorting to any interactive assumptions.
Moving to concrete constructions, we show how to instantiate our framework using class groups of imaginary quadratic fields. Our implementations show that the practical impact of dropping such interactive assumptions is minimal. Indeed, while for 128-bit security our scheme is marginally slower than Lindell’s, for 256-bit security it turns out to be better both in key generation and signing time. Moreover, in terms of communication cost, our implementation significantly reduces both the number of rounds and the transmitted bits without exception.

譯: ECDSA(橢圓曲線數字簽名)是一個被廣泛采用的資料簽名標準,但不幸的是ECDSA的密碼學原語卻很難實作高效的分布式變種方案,且經常需要高昂的零知識證明去處理惡意攻擊,從現有兩方的案例上看,Lindell最近有做出了一個有效的解決方案去實作基于模擬的安全1,該方案依賴于一個互動式非標準的Paillier密碼體制的假設,本論文中我們歸納了Lindell使用hash證明體制的解決方案,而我們的泛用方法的主要優勢在于它無需進行任何互動式的假設即可實作基于模擬的安全,在具體的構造上,我們用虛二次域類群2來展示我們怎么實體化方案架構的,我們的實作表明(在Lindell方案上)洗掉此類的互動式假設的實際影響較小,事實而言,在128-bit安全等級下我們的方案比Lindell的要慢一些,但是在256-bit安全等級下,它在密鑰生成和簽名時間上都比Lindell的方案要好,此外,在通信開銷上,我們的方案顯著減少了輪換次數并且沒有遺漏任何傳輸位元,

引言

引言圖片1
門限密碼學中允許 n n n個使用者以某種方式去共享一個通用密鑰,任何 t t t方( t t t為門限閾值)的子集都可以使用這個通用密鑰去解密或者簽名,這個而任何小于t的聯盟都無能為力去解密或簽名,這個范例的關鍵特征在于它允許使用無需重構的共享密鑰,這意味著每當密鑰被使用(去簽名/解密)時, t t t方子集中人員就必須積極參與,
門限密碼學應用范圍比較廣,從多個簽名者需要簽署同一份檔案到分布式場景下敏感檔案需要被定額人數授權,這種多用途引發了對門限密碼學研究的熱潮,主要表征在1990年早期到2000年早期,產生了最廣泛被使用的門限密碼學方案,因為如下的原因近些年可以看出在這個領域的研究興趣又一次高漲:首先,很多初創公司正在使用這種技術去保護現實生活中的應用程式,此外,對于使用ECDSA作為基礎簽名方案的位元幣和其他加密貨幣,即有安全漏洞就會導致實際的金融損失的數字貨幣類,雖說基于多重簽名的對策已經內置到位元幣中,但它們提供的靈活性較差并且在匿名以及可伸縮性上產生了問題(見[GGN16]),最后,一些20年前被開發出的方案并不能滿足當前應用程式所希望的那樣高效,像ECDSA/DSA簽名就是如此,事實上,對于許多其他方案,快速門限變種(例如RSA解密/簽名和ECIES解密)是已知的構造其簽名的有效門限變種比證明它們要困難得多,這種不對等的原因似乎是需要從一個未知 k k k中反推計算出 k ? 1 m o d q k^{-1}mod q k?1modq的結果困難造成的(這邊意譯),為了解釋為何如此,讓我們首先簡單回顧一下ECDSA是如何實際運作的,公鑰是一個橢圓曲線上的點 Q Q Q并且簽名密鑰是 x x x,像 Q ← x P Q\leftarrow xP QxP,其中 P P P是一個橢圓曲線上基于 q q q階的生成的點,為了簽名訊息 m m m首先要用一些合適的hah函式 H H H對其進行hash處理,然后根據以下演算法步驟進行處理:

  1. Z / q Z Z/qZ Z/qZ中選擇亂數 k k k
  2. 計算 R ← k P R\leftarrow kP RkP
  3. r ← r x m o d q r\leftarrow r_{x}\ mod\ q rrx? mod q 其中 R = { r x , r y } R=\{r_{x},\ r_{y}\} R={rx?, ry?}
  4. 設定 s ← k ? 1 ( H ( m ) + r x ) m o d q s\leftarrow k^{-1}(H(m) + rx)\ mod\ q sk?1(H(m)+rx) mod q
  5. 輸出 ( r , s ) (r, s) (r,s)
    引言圖片2
    現在,最自然實作以上演算法分配步驟應是在參與方之間分享并累加 x x x,然后開始用一個多方計算協議去產生簽名,在兩方案例中,這意味著參與方需開始共享 x 1 x_1 x1? x 2 x_2 x2?使得 Q = ( x 1 + x 2 ) P Q=(x_1+x_2)P Q=(x1?+x2?)P,參與方可以繼續產生亂數 k 1 k_1 k1? k 2 k_2 k2?進行共享,使得 R = ( k 1 + k 2 ) P R=(k_1+k_2)P R=(k1?+k2?)P,然而在這一點上如何有效地計算 k 1 ′ , k 2 ′ k^{'}_1,k^{'}_2 k1?,k2?使得 k 1 ′ + k 2 ′ = k ? 1 m o d q k^{'}_1+k^{'}_2=k^{-1}\ mod\ q k1?+k2?=k?1 mod q并不是很清晰,
    從論文[MR04]開始,兩方ECDSA簽名協議開始在 x x x k k k間采用共通乘法方式共享,構建的基本思路是非常簡單的,參與方起初持有 x 1 x_1 x1? x 2 x_2 x2?使得 Q = x 1 x 2 P = x P Q=x_1x_2P=xP Q=x1?x2?P=xP,每當新簽名產生時,他們產生亂數 k 1 , k 2 k_1,k_2 k1?k2?使得 R = k 1 k 2 P = k P R=k_1k_2P=kP R=k1?k2?P=kP,顯然,這樣的方式將允許獲得反置 k ′ k^{'} k,即 ( k 1 ′ ) ? 1 ( k 2 ′ ) ? 1 = ( k 1 k 2 ) ? 1 m o d q (k^{'}_1)^{-1}(k^{'}_2)^{-1}=(k_1k_2)^{-1}\ mod\ q (k1?)?1(k2?)?1=(k1?k2?)?1 mod q,最后他們將會用Paillier的同態加密方案去秘密添加他們自己秘密并完成簽名,舉例而言,就是參與方 P 1 P_1 P1?計算 c 1 ← E n c ( ( k 1 ) ? 1 H ( m ) ) c_1\leftarrow Enc((k_1)^{-1}H(m)) c1?Enc((k1?)?1H(m)) c 2 ← E n c ( ( k 1 ) ? 1 x 1 r ) c_2\leftarrow Enc((k_1)^{-1}x_1r) c2?Enc((k1?)?1x1?r),然后 P 2 P_2 P2?可以利用方案中的同態特性完成簽名,如下:
    c ← c 1 k 2 ? 1 c 2 k 2 ? 1 x 2 = E n c ( ( k 1 ) ? 1 H ( m ) ) E n c ( ( k 1 ) ? 1 x 1 r ) = E n c ( k ? 1 ( H ( m ) + x r ) ) c\leftarrow c_1^{k_2^{-1}}c_2^{k_2^{-1}x_2 }= Enc((k_1)^{-1}H(m))Enc((k_1)^{-1}x_1r)=Enc(k^{-1}(H(m)+xr)) cc1k2?1??c2k2?1?x2??=Enc((k1?)?1H(m))Enc((k1?)?1x1?r)=Enc(k?1(H(m)+xr))
    引言圖片3
    P 2 P_2 P2?通過將 c c c發回給 P 1 P_1 P1?來結束協議,現在,如果 P 1 P_1 P1?也知道解密密鑰,那么他就能夠從 c c c中提取簽名 s ← k ? 1 ( H ( m ) + x r ) s\leftarrow k^{-1}(H(m)+xr) sk?1(H(m)+xr)
    但是,證明各方都正確遵守了協議是很難的,最初的嘗試[MR04]通過高昂的零知識證明解決了這一問題,此外最近Lindell在[Lin17]中提供了一個更加簡便和有效的協議,Lindell的協議的關鍵思路是有觀察到在上述兩方ECDSA簽名協議中,不誠實方能制造非常小的麻煩,但事實上,如果在準備階段, P 2 P_2 P2?同時收到了Paillier方案中要用的加密密鑰和 P 1 P_1 P1?的簽名密鑰的加密 E n c ( x 1 ) Enc(x_1) Enc(x1?),那么根本上來說,一個不誠實的 P 1 P_1 P1?能做的就是參與 R ← k 1 k 2 P R\leftarrow k_1k_2P Rk1?k2?P的產生,但需要注意后者建立在DH協議基礎之上,是非常有效且魯棒性的協議,
    引言圖片4
    另一方面,如果 P 2 P_2 P2?不誠實,那么她能做的就是(除了再次產生一個R)去構造一個有損害的 c c c作為最終反饋給 P 1 P_1 P1?的結果,但是,當 P 2 P_2 P2?真的嘗試那樣做的話,那么通過簡單驗證結果簽名的合法性將很容易檢測到它的惡意行為,
    但是實際證明的話將會引發一些問題,首先第一個問題是由Paillier的明文空間是 Z / N Z Z/NZ Z/NZ N N N是一個大合數)而ECDSA簽名依賴于 Z / q Z Z/qZ Z/qZ q q q是素數),因此為了避免這個不一致的問題,需要確保將 N N N取得足夠大,以便在整個簽名程序中不會發生wrap-around情形3,這也意味著將 E n c ( x 1 ) Enc(x_1) Enc(x1?)發送給 P 2 P_2 P2?時, P 1 P_1 P1?需要證明明文 x 1 x_1 x1?在正確的范圍內(即足夠小),
    在此證明中使用Paillier加密會產生一個微小的問題,事實上,如果要使用該方案在實際和模擬的執行中分辨敵手的不可區分性,似乎有必要設定一個關于Paillier密碼體系不可區分性的規約, 這意味著必須設計一種證明技術,該技術可以成功使用Paillier加密方案而無需知道相應的密鑰, 根據Lindell的協議,在設計基于模擬的安全策略來應對有惡意參與方 P 2 P_2 P2?時會出現問題, 在這種情形下, P 2 P_2 P2?確實可能會發送一個錯誤的密文 c c c(即不對簽名進行加密)而模擬器根本無法將其識別為錯誤的密文,
    Lindell [Lin17]提出了兩種可替代的證明來克服這一問題, 第一個依靠一個基于博弈的定義,并通過允許仿真模擬器例外終止來避免該問題,概率取決于已提出簽名 q s q_s qs?的數量, 但這似乎導致了不緊密的安全性證明(因為規約減少了一個 q s q_s qs?因子), 第二個證明是基于模擬的定義避免例外終止,但需要引入有關Paillier加密案的新的互動式的非標準假設,
    因此,可以說,盡管該領域最近有取得了進展,但仍然存在以下公開的問題:
    是否有可能設計出一種實用的兩方ECDSA簽名協議(兩者都就計算效率和帶寬消耗而言)不需要互動性假設并允許一個嚴密的安全規約?

總結

總結圖片
受到Lindell方案的啟發,我們提出了第一個哈希證明系統的兩方ECDSA簽名的通用構造,系統構造是基于同質模數的,理論上來說,由于底層語意安全的同態加密方案的結構,我們的構造可以實作基于模擬的安全性證明,該證明即嚴格且無需互動性假設,事實上而言,我們使用CL框架從虛數二次域類組提供詳細的實體化案并用C實作,與Lindell的基于Paillier的方案相比,在高級別的安全性方面,它產生了更好的性能;在標準級別上(128bit),它具有同樣數量級,我們的解決方案在192bit以后的安全等級上比Lindell的運算要快,虛二次域中理想4算術的進步可能會帶來改進(見[IJS10]實體)基于類組的可驗證延遲功能也應激發該領域的最新研究(例如Chia 網路[Chi]也為此展開了競爭),


這一段有點翻譯和理解有些困難,后續進行更新改進,


最后,我們的作業聚焦在兩方案例下,我們相信我們構造方案的想法將引發門限ECDSA簽名案例的改善,我們留至下一步作業,


  1. 密碼學證明安全性有兩種方式:一種是基于博弈的安全 [Game-based Security],另一種是基于模擬的安全 [Simulation-based Security] ,關于兩者的區別分析請移至以下連接參考; ??

  2. 代數數論中的一個常見概念,在代數數論中,二次域是在有理數域 Q \mathbb{Q} Q上次數為二的數域,二次域可以唯一地表成 Q ( d ) \displaystyle \mathbb {Q} ({\sqrt {d}}) Q(d ?),其中 d d d無平方數約數,若 d > 0 d>0 d>0,稱之為實二次域;否則稱為虛二次域或復二次域,虛實之分在于 Q ( d ) \mathbb {Q} ({\sqrt {d}}) Q(d ?)是否為全實域,wiki百科地址; ??

  3. 當乘法轉換為密文時,稱為warp-around情形(此點后續進行擴充描述) ??

  4. 環論概念 ??

轉載請註明出處,本文鏈接:https://www.uj5u.com/shujuku/158495.html

標籤:其他

上一篇:Mac OS 區塊鏈hyperledger環境搭建、環境架構介紹、環境如何用、部署 Chaincode、智能合約的呼叫

下一篇:為什么unordered_map桶的大小是8?

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • GPU虛擬機創建時間深度優化

    **?桔妹導讀:**GPU虛擬機實體創建速度慢是公有云面臨的普遍問題,由于通常情況下創建虛擬機屬于低頻操作而未引起業界的重視,實際生產中還是存在對GPU實體創建時間有苛刻要求的業務場景。本文將介紹滴滴云在解決該問題時的思路、方法、并展示最終的優化成果。 從公有云服務商那里購買過虛擬主機的資深用戶,一 ......

    uj5u.com 2020-09-10 06:09:13 more
  • 可編程網卡芯片在滴滴云網路的應用實踐

    **?桔妹導讀:**隨著云規模不斷擴大以及業務層面對延遲、帶寬的要求越來越高,采用DPDK 加速網路報文處理的方式在橫向縱向擴展都出現了局限性。可編程芯片成為業界熱點。本文主要講述了可編程網卡芯片在滴滴云網路中的應用實踐,遇到的問題、帶來的收益以及開源社區貢獻。 #1. 資料中心面臨的問題 隨著滴滴 ......

    uj5u.com 2020-09-10 06:10:21 more
  • 滴滴資料通道服務演進之路

    **?桔妹導讀:**滴滴資料通道引擎承載著全公司的資料同步,為下游實時和離線場景提供了必不可少的源資料。隨著任務量的不斷增加,資料通道的整體架構也隨之發生改變。本文介紹了滴滴資料通道的發展歷程,遇到的問題以及今后的規劃。 #1. 背景 資料,對于任何一家互聯網公司來說都是非常重要的資產,公司的大資料 ......

    uj5u.com 2020-09-10 06:11:05 more
  • 滴滴AI Labs斬獲國際機器翻譯大賽中譯英方向世界第三

    **桔妹導讀:**深耕人工智能領域,致力于探索AI讓出行更美好的滴滴AI Labs再次斬獲國際大獎,這次獲獎的專案是什么呢?一起來看看詳細報道吧! 近日,由國際計算語言學協會ACL(The Association for Computational Linguistics)舉辦的世界最具影響力的機器 ......

    uj5u.com 2020-09-10 06:11:29 more
  • MPP (Massively Parallel Processing)大規模并行處理

    1、什么是mpp? MPP (Massively Parallel Processing),即大規模并行處理,在資料庫非共享集群中,每個節點都有獨立的磁盤存盤系統和記憶體系統,業務資料根據資料庫模型和應用特點劃分到各個節點上,每臺資料節點通過專用網路或者商業通用網路互相連接,彼此協同計算,作為整體提供 ......

    uj5u.com 2020-09-10 06:11:41 more
  • 滴滴資料倉庫指標體系建設實踐

    **桔妹導讀:**指標體系是什么?如何使用OSM模型和AARRR模型搭建指標體系?如何統一流程、規范化、工具化管理指標體系?本文會對建設的方法論結合滴滴資料指標體系建設實踐進行解答分析。 #1. 什么是指標體系 ##1.1 指標體系定義 指標體系是將零散單點的具有相互聯系的指標,系統化的組織起來,通 ......

    uj5u.com 2020-09-10 06:12:52 more
  • 單表千萬行資料庫 LIKE 搜索優化手記

    我們經常在資料庫中使用 LIKE 運算子來完成對資料的模糊搜索,LIKE 運算子用于在 WHERE 子句中搜索列中的指定模式。 如果需要查找客戶表中所有姓氏是“張”的資料,可以使用下面的 SQL 陳述句: SELECT * FROM Customer WHERE Name LIKE '張%' 如果需要 ......

    uj5u.com 2020-09-10 06:13:25 more
  • 滴滴Ceph分布式存盤系統優化之鎖優化

    **桔妹導讀:**Ceph是國際知名的開源分布式存盤系統,在工業界和學術界都有著重要的影響。Ceph的架構和演算法設計發表在國際系統領域頂級會議OSDI、SOSP、SC等上。Ceph社區得到Red Hat、SUSE、Intel等大公司的大力支持。Ceph是國際云計算領域應用最廣泛的開源分布式存盤系統, ......

    uj5u.com 2020-09-10 06:14:51 more
  • es~通過ElasticsearchTemplate進行聚合~嵌套聚合

    之前寫過《es~通過ElasticsearchTemplate進行聚合操作》的文章,這一次主要寫一個嵌套的聚合,例如先對sex集合,再對desc聚合,最后再對age求和,共三層嵌套。 Aggregations的部分特性類似于SQL語言中的group by,avg,sum等函式,Aggregation ......

    uj5u.com 2020-09-10 06:14:59 more
  • 爬蟲日志監控 -- Elastc Stack(ELK)部署

    傻瓜式部署,只需替換IP與用戶 導讀: 現ELK四大組件分別為:Elasticsearch(核心)、logstash(處理)、filebeat(采集)、kibana(可視化) 下載均在https://www.elastic.co/cn/downloads/下tar包,各組件版本最好一致,配合fdm會 ......

    uj5u.com 2020-09-10 06:15:05 more
最新发布
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:33:24 more
  • MySQL中binlog備份腳本分享

    關于MySQL的二進制日志(binlog),我們都知道二進制日志(binlog)非常重要,尤其當你需要point to point災難恢復的時侯,所以我們要對其進行備份。關于二進制日志(binlog)的備份,可以基于flush logs方式先切換binlog,然后拷貝&壓縮到到遠程服務器或本地服務器 ......

    uj5u.com 2023-04-20 08:28:06 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:27:27 more
  • 快取與資料庫雙寫一致性幾種策略分析

    本文將對幾種快取與資料庫保證資料一致性的使用方式進行分析。為保證高并發性能,以下分析場景不考慮執行的原子性及加鎖等強一致性要求的場景,僅追求最終一致性。 ......

    uj5u.com 2023-04-20 08:26:48 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:26:35 more
  • 云時代,MySQL到ClickHouse資料同步產品對比推薦

    ClickHouse 在執行分析查詢時的速度優勢很好的彌補了MySQL的不足,但是對于很多開發者和DBA來說,如何將MySQL穩定、高效、簡單的同步到 ClickHouse 卻很困難。本文對比了 NineData、MaterializeMySQL(ClickHouse自帶)、Bifrost 三款產品... ......

    uj5u.com 2023-04-20 08:26:29 more
  • sql陳述句優化

    問題查找及措施 問題查找 需要找到具體的代碼,對其進行一對一優化,而非一直把關注點放在服務器和sql平臺 降低簡化每個事務中處理的問題,盡量不要讓一個事務拖太長的時間 例如檔案上傳時,應將檔案上傳這一步放在事務外面 微軟建議 4.啟動sql定時執行計劃 怎么啟動sqlserver代理服務-百度經驗 ......

    uj5u.com 2023-04-20 08:25:13 more
  • Redis 報”OutOfDirectMemoryError“(堆外記憶體溢位)

    Redis 報錯“OutOfDirectMemoryError(堆外記憶體溢位) ”問題如下: 一、報錯資訊: 使用 Redis 的業務介面 ,產生 OutOfDirectMemoryError(堆外記憶體溢位),如圖: 格式化后的報錯資訊: { "timestamp": "2023-04-17 22: ......

    uj5u.com 2023-04-20 08:24:54 more
  • day02-2-商鋪查詢快取

    功能02-商鋪查詢快取 3.商鋪詳情快取查詢 3.1什么是快取? 快取就是資料交換的緩沖區(稱作Cache),是存盤資料的臨時地方,一般讀寫性能較高。 快取的作用: 降低后端負載 提高讀寫效率,降低回應時間 快取的成本: 資料一致性成本 代碼維護成本 運維成本 3.2需求說明 如下,當我們點擊商店詳 ......

    uj5u.com 2023-04-20 08:24:03 more
  • day02-短信登錄

    功能實作02 2.功能01-短信登錄 2.1基于Session實作登錄 2.1.1思路分析 2.1.2代碼實作 2.1.2.1發送短信驗證碼 發送短信驗證碼: 發送驗證碼的介面為:http://127.0.0.1:8080/api/user/code?phone=xxxxx<手機號> 請求方式:PO ......

    uj5u.com 2023-04-20 08:23:11 more