• 
    

    
    

      99热精品在线国产_美女午夜性视频免费_国产精品国产高清国产av_av欧美777_自拍偷自拍亚洲精品老妇_亚洲熟女精品中文字幕_www日本黄色视频网_国产精品野战在线观看 ?

      基于門限代理重加密和IPFS的數(shù)據(jù)去中心化安全共享方案

      2021-02-25 11:07:58喬雙全王勁松
      關(guān)鍵詞:公鑰密文解密

      喬雙全,王勁松

      (天津理工大學(xué)計(jì)算機(jī)科學(xué)與工程學(xué)院,天津300384)

      隨著信息技術(shù)的發(fā)展,大數(shù)據(jù)的量級(jí)正以指數(shù)級(jí)的速度增長,數(shù)據(jù)已經(jīng)成為促進(jìn)產(chǎn)業(yè)發(fā)展的重要驅(qū)動(dòng)力.但是當(dāng)前大數(shù)據(jù)產(chǎn)業(yè)面臨著“人人有數(shù)據(jù),人人缺數(shù)據(jù)”的“數(shù)據(jù)孤島”式困境,將這些分散的大數(shù)據(jù)互連共享,從而獲得數(shù)據(jù)中潛在的巨大價(jià)值,是科研、政務(wù)、商業(yè)、公共服務(wù)等領(lǐng)域共同存在的迫切需求[1].傳統(tǒng)的多方數(shù)據(jù)共享方案大多是基于第三方云存儲(chǔ)系統(tǒng)的,這種模式依賴于中心化的存儲(chǔ)服務(wù),存在單點(diǎn)故障和隱私安全風(fēng)險(xiǎn).當(dāng)數(shù)據(jù)的所有權(quán)由數(shù)據(jù)擁有者掌控轉(zhuǎn)變?yōu)橛晒性频鹊谌綄?shí)體管理者所掌控時(shí),威脅場景會(huì)發(fā)生根本變化[2].在這種情況下,數(shù)據(jù)共享者不僅面臨著來自網(wǎng)絡(luò)攻擊者對(duì)本地?cái)?shù)據(jù)的攻擊威脅,還將承擔(dān)云存儲(chǔ)提供商遭受內(nèi)部或外部惡意攻擊的風(fēng)險(xiǎn).此外,集中式的數(shù)據(jù)存儲(chǔ)機(jī)制容易遭受單點(diǎn)故障問題,數(shù)據(jù)的可靠性完全取決于云存儲(chǔ)服務(wù)商的軟硬件的可靠性.應(yīng)對(duì)這些威脅的方法主要包括加強(qiáng)數(shù)據(jù)訪問控制策略、改進(jìn)內(nèi)部監(jiān)督機(jī)制以及改進(jìn)災(zāi)難恢復(fù)和數(shù)據(jù)備份機(jī)制等,但這些措施實(shí)際上僅僅將威脅轉(zhuǎn)化為信任問題.事實(shí)上,并沒有實(shí)際有效的機(jī)制來防止這些中心化的云存儲(chǔ)服務(wù)商無意或有意地破壞這些措施.

      為了確保數(shù)據(jù)的隱私安全,在共享數(shù)據(jù)的時(shí)候,需要對(duì)數(shù)據(jù)進(jìn)行加密處理.廣泛使用的公鑰加密方案提供了很好的安全性,但其加密性能不高,特別是在多方數(shù)據(jù)共享的情況下,數(shù)據(jù)發(fā)送者必須針對(duì)多個(gè)解密者使用其公鑰進(jìn)行重復(fù)的加密操作.當(dāng)數(shù)據(jù)提供者是算力不足的設(shè)備時(shí),多次重復(fù)的加密操作大大增加了設(shè)備的運(yùn)算負(fù)擔(dān).

      在數(shù)據(jù)共享的研究領(lǐng)域中,目前已有廣泛使用的基于點(diǎn)對(duì)點(diǎn)(Peer-to-Peer,P2P)技術(shù)的去中心化的文件共享方案,如基于BitTorrent內(nèi)容分發(fā)協(xié)議的共享方案,和基于分布式哈希表(Distributed Hash Table,DHT[3])技術(shù)的共享方案.但這些技術(shù)僅僅做到了數(shù)據(jù)的去中心化共享,沒有使用加密技術(shù)保證數(shù)據(jù)的隱私性和安全性.基于云計(jì)算的數(shù)據(jù)共享方案中,研究人員提出了多種保護(hù)數(shù)據(jù)安全及隱私的方法.Li等人[4]提出了一種新的基于屬性的數(shù)據(jù)共享方案,適用于云計(jì)算中資源有限的移動(dòng)用戶.Dong等人[5]提出了一種利用密文策略屬性加密結(jié)合身份加密的數(shù)據(jù)共享方案,來提供安全可靠的云數(shù)據(jù)共享服務(wù).Liu等人[6]提出一種利用組簽名和動(dòng)態(tài)廣播加密技術(shù)的多用戶數(shù)據(jù)共享方案,允許任何云用戶匿名地與他人共享數(shù)據(jù).然而這些方案仍然依賴于云服務(wù)進(jìn)行數(shù)據(jù)共享,無法從源頭上解決中心化帶來的數(shù)據(jù)安全問題和隱私問題.

      本文提出一種新的去中心化的安全的數(shù)據(jù)共享方案,該方案的創(chuàng)新點(diǎn)如下:1)采用門限代理重加密方法解決了多方數(shù)據(jù)共享場景下加密低效的問題,可以保證數(shù)據(jù)安全并降低共謀風(fēng)險(xiǎn).2)采用IPFS技術(shù)解決了數(shù)據(jù)的中心化問題,并提高了多方數(shù)據(jù)共享場景下的數(shù)據(jù)傳輸效率.

      1 理論基礎(chǔ)

      1.1 代理重加密

      代理重加密(Proxy Re-Encryption,PRE)的概念最早由Blaze、Bleumer和Strauss在文獻(xiàn)[7]中提出.代理重加密是一種特殊類型的公鑰加密,它允許代理將由加密者公鑰加密的密文轉(zhuǎn)換為由解密者公鑰加密的密文,在這個(gè)過程中代理無法獲取有關(guān)原始數(shù)據(jù)的任何信息.代理需要獲取擁有密文的原始加密者通過其私鑰和解密者的公鑰生成的重加密密鑰,然后使用該重加密密鑰對(duì)密文進(jìn)行轉(zhuǎn)換.解密者從代理獲取重加密后的密文,然后可以使用自己的私鑰解密文件.

      圖1描述了一個(gè)典型的代理重新加密模型,該模型由授權(quán)者Alice、被授權(quán)者Bob和代理Proxy組成.數(shù)據(jù)所有者Alice擁有公鑰pkA,她(或者擁有pkA的實(shí)體)可以用pkA對(duì)消息m進(jìn)行加密,從而生成只有她才能使用其密鑰skA解密的密文cA.Alice決定將消息m的訪問權(quán)限委托給擁有密鑰對(duì)(pkB,skB)的Bob.為此,Alice創(chuàng)建一個(gè)重加密密鑰:rkA→B=rekey(skA,pkB)并將其發(fā)送給代理.代理用rkA→B對(duì)cA重新加密,得到用pkB加密的密文cB.Bob可以用他的密鑰skB解密cB,得到原始消息m.

      圖1代理重加密Fig.1 Proxy re-encryption

      1.2 門限代理重加密

      門限代理重加密采用了t-of-n架構(gòu)的多代理方案,將重加密權(quán)限分散到了n個(gè)代理節(jié)點(diǎn),分割了單代理節(jié)點(diǎn)的信任風(fēng)險(xiǎn),并允許在有部分代理節(jié)點(diǎn)發(fā)生故障的情況下,仍可完成重加密操作.每個(gè)代理節(jié)點(diǎn)對(duì)密文進(jìn)行重加密操作生成重加密后的密文片段,解密者只要收集達(dá)到門限值t數(shù)量的重加密的密文片段后,就可以使用自己的私鑰解密密文.

      門限代理重加密方案基于KEM/DEM混合加密實(shí)現(xiàn),Cramer和Shoup[8]最早對(duì)混合加密進(jìn)行了系統(tǒng)化研究,并提出密鑰封裝機(jī)制(Key Encryption Mechanism,KEM)和數(shù)據(jù)封裝機(jī)制(Data Encryption Mechanism,DEM)的概念.

      在典型的門限代理重加密場景中,實(shí)體分為數(shù)據(jù)發(fā)送者Alice、n個(gè)代理節(jié)點(diǎn)Proxyi(i=1,2,…,n)和數(shù)據(jù)接收者(Bob).加密、重加密和解密的過程如下:

      Alice首先運(yùn)行KEM的密鑰生成算法,通過自己的公鑰pkA生成一個(gè)對(duì)稱密鑰K和K的密文c1,使用K加密消息m得到密文c2,并把c1和c2發(fā)送給Bob;

      Alice獲取Bob的公鑰pkB,運(yùn)行KEM的密鑰生成算法,通過自己的私鑰pkA和Bob的公鑰pkB生成n個(gè)重加密密鑰片段ki(i=1,2,…,n),并把ki發(fā)送給代理節(jié)點(diǎn)Proxyi;

      代理節(jié)點(diǎn)Proxyi運(yùn)行KEM的密鑰生成算法,通過ki對(duì)c1進(jìn)行重加密操作,生成密文片段ci,并把ci發(fā)送給Bob;

      Bob從n個(gè)代理節(jié)點(diǎn)收集至少達(dá)到閾值t數(shù)量的有效密文片段ci,然后可以用自己的私鑰skB和至少t個(gè)有效密文片段ci將密文c1恢復(fù)成對(duì)稱密鑰K;

      Bob運(yùn)行DEM的數(shù)據(jù)解密算法,通過對(duì)稱密鑰K解密密文c2得到原始消息m.

      1.3 IPFS

      星際文件系統(tǒng)(InterPlanetary File System,IPFS)是一個(gè)用于在分布式文件系統(tǒng)中存儲(chǔ)和共享數(shù)據(jù)的協(xié)議和對(duì)等網(wǎng)絡(luò).它綜合了現(xiàn)有的對(duì)等網(wǎng)絡(luò)協(xié)議和系統(tǒng)的成功思想,包括分布式哈希表(Distributed Hash Table,DHT)、BitTorrent、Git和SFS,將這些技術(shù)融合、發(fā)展,使之成為一個(gè)擁有以上技術(shù)所有優(yōu)秀特性的綜合的內(nèi)聚系統(tǒng).

      IPFS也是一個(gè)分布式的超媒體傳輸協(xié)議,旨在補(bǔ)充甚至取代傳統(tǒng)的超文本傳輸協(xié)議HTTP.傳統(tǒng)的HTTP協(xié)議是中心化的,當(dāng)你從網(wǎng)站下載文件時(shí),HTTP協(xié)議一次只能從一臺(tái)計(jì)算機(jī)下載文件,而不是同時(shí)從多臺(tái)計(jì)算機(jī)下載文件.與HTTP協(xié)議不同,IPFS可以在對(duì)等模式下同時(shí)從多臺(tái)計(jì)算機(jī)下載相同的文件,從而可以容忍單點(diǎn)失效問題.IPFS的另一個(gè)重要特征是內(nèi)容尋址,這也與HTTP協(xié)議有著根本的不同(當(dāng)你使用HTTP協(xié)議訪問網(wǎng)絡(luò)上的文件時(shí),你必須知道文件的網(wǎng)址,這意味著HTTP是通過網(wǎng)址定位互聯(lián)網(wǎng)上的文件).當(dāng)使用IPFS添加文件時(shí),文件以及其中的所有塊都將被賦予一個(gè)稱為加密哈希的唯一指紋,該指紋在IPFS網(wǎng)絡(luò)中唯一標(biāo)識(shí)該文件.其他節(jié)點(diǎn)可以通過加密哈希訪問文件.當(dāng)其他節(jié)點(diǎn)有相同的文件時(shí),可以使用加密哈希同時(shí)從多個(gè)節(jié)點(diǎn)下載該文件.

      2 基于門限代理重加密和IPFS的數(shù)據(jù)共享機(jī)制

      2.1 數(shù)據(jù)共享模型

      本方案的模型如圖2所示,該模型描述了多方數(shù)據(jù)共享場景下的數(shù)據(jù)的加密、重加密、解密以及傳輸?shù)倪^程.該模型中存在以下實(shí)體:

      Alice:Alice是數(shù)據(jù)發(fā)送者,她用自己的公鑰加密數(shù)據(jù)文件,并為代理節(jié)點(diǎn)生成重加密密鑰片段.

      Bob,Carl,David:Bob、Carl和David是數(shù)據(jù)接收者,他們從IPFS網(wǎng)絡(luò)中獲取加密的數(shù)據(jù)文件,并用各自的私鑰解密文件.

      Proxy1~ProxyN:Proxy1~ProxyN是N個(gè)代理節(jié)點(diǎn),他們使用數(shù)據(jù)接收者的公鑰對(duì)用Alice公鑰加密的文件進(jìn)行重加密操作.

      Eve:Eve是假想的潛在攻擊者,他可以對(duì)系統(tǒng)進(jìn)行惡意攻擊.

      模型中所有的實(shí)體都處于同一個(gè)IPFS私有網(wǎng)絡(luò),數(shù)據(jù)存儲(chǔ)在本地,不存在中心化的存儲(chǔ)節(jié)點(diǎn).每個(gè)實(shí)體可以通過本地的IPFS網(wǎng)關(guān)獲取IPFS網(wǎng)絡(luò)中的數(shù)據(jù)文件.數(shù)據(jù)上傳到IPFS網(wǎng)絡(luò)后會(huì)生成對(duì)應(yīng)的IPFS加密哈希地址,用于在私有網(wǎng)絡(luò)中唯一標(biāo)志該文件,私有網(wǎng)絡(luò)中任何得到該地址的實(shí)體都可以在IPFS網(wǎng)絡(luò)中下載該文件.并且在多方數(shù)據(jù)共享的場景下,如果數(shù)據(jù)被多個(gè)節(jié)點(diǎn)下載過,那么在新節(jié)點(diǎn)下載該數(shù)據(jù)時(shí)便可以在多個(gè)節(jié)點(diǎn)中同時(shí)下載,從而顯著提高多方數(shù)據(jù)共享時(shí)的數(shù)據(jù)傳輸效率.并且因?yàn)樵摲桨覆灰蕾囉谥行幕拇鎯?chǔ)服務(wù),因此可以避免中心化帶來的單點(diǎn)故障問題和隱私泄露問題.

      該模型使用門限代理重加密保證數(shù)據(jù)的隱私,在多方數(shù)據(jù)共享的場景下,數(shù)據(jù)發(fā)送者只需要使用自己的公鑰對(duì)數(shù)據(jù)進(jìn)行一次加密,然后授權(quán)給解密者解密權(quán)限,多個(gè)代理節(jié)點(diǎn)會(huì)對(duì)加密數(shù)據(jù)進(jìn)行重加密操作,生成對(duì)應(yīng)的密文片段.解密者收集到足夠的(達(dá)到門限值)密文片段后,可以使用自己的私鑰解密數(shù)據(jù).因?yàn)閠-of-n架構(gòu)的代理重加密機(jī)制,本方案允許部分代理節(jié)點(diǎn)失效,從而在代理重加密層面避免了中心化的單點(diǎn)失效問題,并且多代理節(jié)點(diǎn)的存在,增加了解密者與代理節(jié)點(diǎn)共謀的難度,降低了共謀攻擊的風(fēng)險(xiǎn).

      圖2數(shù)據(jù)共享模型Fig.2 File sharing model

      2.2 威脅模型

      本文通過討論系統(tǒng)中實(shí)體的威脅行為來定義系統(tǒng)的威脅模型.定義如下:

      數(shù)據(jù)發(fā)送者:本文假定數(shù)據(jù)發(fā)送者是誠實(shí)的,即數(shù)據(jù)是真實(shí)的,但是系統(tǒng)中存在惡意節(jié)點(diǎn)冒充真實(shí)數(shù)據(jù)發(fā)送者的可能性.

      數(shù)據(jù)接收者:本文假定數(shù)據(jù)接收者是惡意的,他們可以和代理節(jié)點(diǎn)共謀而繞過重加密的限制,并且可以在系統(tǒng)之外勒索數(shù)據(jù)提供者.

      代理節(jié)點(diǎn):本文假定代理節(jié)點(diǎn)是半可信的,他們中的某些節(jié)點(diǎn)可能會(huì)偷窺數(shù)據(jù)內(nèi)容或者執(zhí)行不誠實(shí)加密.

      潛在攻擊者:潛在攻擊者是惡意的,他們?cè)谙到y(tǒng)內(nèi)部或外部并想要破化該系統(tǒng).

      本文不考慮以下問題:數(shù)據(jù)接收者主動(dòng)泄露解密的數(shù)據(jù).如果他們被授予加密數(shù)據(jù)的解密權(quán)限,那么他們就被授予數(shù)據(jù)的讀取權(quán)限,因此一旦信息被發(fā)布,任何訪問控制系統(tǒng)都不能阻止它被泄露.

      2.3 數(shù)據(jù)共享流程

      下面根據(jù)圖2所示模型圖介紹該模型下數(shù)據(jù)共享的流程:

      1Alice使用自己的公鑰pkA對(duì)文件F進(jìn)行加密,生成加密文件Fe.然后將其上傳到IPFS網(wǎng)絡(luò),生成對(duì)應(yīng)的IPFS加密哈希地址;

      2Alice使用其私鑰skA,Bob的公鑰pkB、Carl的公鑰pkC以及David的公鑰pkD,分別為Bob、Carl和David生成對(duì)應(yīng)的重加密密鑰keyr,每個(gè)數(shù)據(jù)接收者對(duì)應(yīng)的重加密密鑰由N個(gè)重加密密鑰片段組成,每個(gè)密鑰片段稱為kFrag;

      3Alice使用每個(gè)代理節(jié)點(diǎn)的公鑰對(duì)密鑰片段kFrag進(jìn)行加密,然后將這N個(gè)加密后的密鑰片段發(fā)給代理節(jié)點(diǎn),每個(gè)代理獲得其中一個(gè)片段.令k為密鑰片段的數(shù)量,t為門限值;

      4每個(gè)代理節(jié)點(diǎn)Proxyi使用自己的私鑰解密kFrag,并從IPFS網(wǎng)絡(luò)中獲取加密文件Fe,并用獲得的重加密密鑰片段kFrag對(duì)該密文進(jìn)行重加密操作,生成重加密后的密文片段Ci,并將其上傳到IPFS網(wǎng)絡(luò);

      3 安全分析

      本文將根據(jù)2.2節(jié)所述的威脅模型討論系統(tǒng)的安全問題.

      3.1 身份偽造問題

      公鑰加密算法允許任何人通過A的公鑰對(duì)數(shù)據(jù)進(jìn)行加密,因此存在惡意用戶冒充A用戶使用其公鑰對(duì)數(shù)據(jù)進(jìn)行惡意加密的可能.為了防止該情況發(fā)生,本文采用數(shù)字簽名的方式向數(shù)據(jù)接收者驗(yàn)證發(fā)送者的身份.數(shù)據(jù)簽名如果直接發(fā)送給數(shù)據(jù)接受者,存在被監(jiān)聽的可能,這會(huì)泄露數(shù)據(jù)發(fā)送者的身份隱私,因?yàn)轵?yàn)證數(shù)據(jù)所有者的公共數(shù)字簽名可以直接確定數(shù)據(jù)的發(fā)送者.本文采用以下方法解決該問題將數(shù)字簽名作為共享數(shù)據(jù)的一部分,因此在密文被解密之前不可能驗(yàn)證簽名.

      使用不同的密鑰對(duì)進(jìn)行簽名和加密(特別是考慮到共謀攻擊的可能性).

      3.2 共謀攻擊問題

      在傳統(tǒng)的代理重加密方案中,由于只存在單一的代理節(jié)點(diǎn),如果該代理節(jié)點(diǎn)和解密者串通,將重加密密鑰直接泄露給解密者,解密者就可以隨意解密數(shù)據(jù),從而繞過基于條件或時(shí)間的任何約束,稱之為共謀攻擊.

      本文采用了密鑰分段形式的門限代理重加密方法,將代理的重加密操作擴(kuò)展到了多個(gè)代理節(jié)點(diǎn),從而在多個(gè)代理節(jié)點(diǎn)之間分散了信任,解密者如果要發(fā)動(dòng)共謀攻擊,需要與至少t個(gè)代理節(jié)點(diǎn)串通,這增加了共謀攻擊的難度.

      3.3 節(jié)點(diǎn)作惡問題

      系統(tǒng)里可能存在的攻擊者,會(huì)對(duì)系統(tǒng)進(jìn)行破壞.攻擊者可能會(huì)對(duì)系統(tǒng)的代理節(jié)點(diǎn)進(jìn)行攻擊,從而破壞加密的過程.因?yàn)楸疚牟捎玫拈T限代理重加密方案擁有多個(gè)代理節(jié)點(diǎn),允許部分代理節(jié)點(diǎn)失效,即使部分代理節(jié)點(diǎn)宕機(jī)也不會(huì)影響數(shù)據(jù)加密過程,這增強(qiáng)了系統(tǒng)的健壯性.攻擊者可能會(huì)通過加入IPFS私有網(wǎng)絡(luò)并監(jiān)聽網(wǎng)絡(luò)通信來竊取系統(tǒng)內(nèi)共享的數(shù)據(jù)的IPFS地址,從而從IPFS網(wǎng)絡(luò)中獲取其他節(jié)點(diǎn)共享的數(shù)據(jù).

      但數(shù)據(jù)的共享過程都是通過加密保護(hù)的,除非數(shù)據(jù)接收者泄露自己的私鑰給攻擊者,否則攻擊者只能獲取加密后的數(shù)據(jù)而無法解密數(shù)據(jù).

      4 實(shí)驗(yàn)與結(jié)果分析

      4.1 實(shí)驗(yàn)環(huán)境

      本次實(shí)驗(yàn)的硬件環(huán)境由部署在服務(wù)器上的10臺(tái)虛擬機(jī)組成,每個(gè)節(jié)點(diǎn)的硬件配置細(xì)節(jié)如表1所示,實(shí)驗(yàn)的軟件環(huán)境如表2所示.

      專家表示,給寶寶適當(dāng)?shù)匮a(bǔ)充益生菌,可以呵護(hù)寶寶腸道健康,是預(yù)防秋冬腹瀉的有效方法之一。而寶寶已經(jīng)有了腹瀉的癥狀時(shí),也可以適當(dāng)補(bǔ)充益生菌,可有效抑制有害致病菌、維持腸道微生態(tài)平衡、增強(qiáng)腸道免疫能力。

      表1節(jié)點(diǎn)硬件配置細(xì)節(jié)Tab.1 Nodes hardware configuration details

      表2系統(tǒng)軟件環(huán)境Tab.2 System software environment

      圖3數(shù)據(jù)的加解密性能測試Fig.3 Data encryption and decryption performance test

      本文構(gòu)建了一個(gè)IPFS私有網(wǎng)絡(luò)來實(shí)現(xiàn)數(shù)據(jù)的去中心化存儲(chǔ)和傳輸.門限代理重加密模塊通過Python3實(shí)現(xiàn),作為對(duì)比測試用的公鑰加密工具選用了開源的eciespy,兩種加密方案都使用secp256k1橢圓曲線.

      4.2 加解密性能測試

      本文在10個(gè)節(jié)點(diǎn)上進(jìn)行了加密和解密的性能測試,Node 5模擬數(shù)據(jù)發(fā)送方,Node 6、7、8、9模擬數(shù)據(jù)接收方,Node 1、2、3、4模擬代理節(jié)點(diǎn).實(shí)驗(yàn)對(duì)本模型采用的門限代理重加密方案和傳統(tǒng)的公鑰加密方案進(jìn)行了性能比較測試.在多方數(shù)據(jù)共享的場景下,數(shù)據(jù)發(fā)送者需要針對(duì)不同的數(shù)據(jù)接收者,分別對(duì)數(shù)據(jù)進(jìn)行加密.但是在解密階段,數(shù)據(jù)接收者的解密過程是相互獨(dú)立的.因此本實(shí)驗(yàn)記錄了數(shù)據(jù)發(fā)送者每次加密的時(shí)間以及在解密階段花費(fèi)時(shí)間最長的節(jié)點(diǎn)所花費(fèi)的時(shí)間.門限代理重加密方案中的多個(gè)代理節(jié)點(diǎn)可以并行獨(dú)立地重加密數(shù)據(jù),因此記錄了重加密過程中花費(fèi)時(shí)間最長的節(jié)點(diǎn)所花費(fèi)的時(shí)間,解密階段也記錄了花費(fèi)時(shí)間最長的節(jié)點(diǎn)所花費(fèi)的時(shí)間.

      圖3顯示了在不同的數(shù)據(jù)量大小下,不同數(shù)量的數(shù)據(jù)接收者對(duì)加解密性能的影響.對(duì)比測試結(jié)果表明,相同的數(shù)據(jù)大小下,本文方案的加解密操作所耗時(shí)間與數(shù)據(jù)接收者數(shù)量關(guān)系不大,公鑰加密方案的加解密操作所耗時(shí)間隨著接收者數(shù)量的增多而以線性速度增長.實(shí)驗(yàn)顯示本文采用的門限代理重加密方案的加解密性能優(yōu)于傳統(tǒng)的公鑰加密方案.特別是當(dāng)數(shù)據(jù)接收者數(shù)量越多時(shí),兩者的性能差距越明顯.

      4.3 數(shù)據(jù)傳輸性能測試

      本文對(duì)系統(tǒng)中采用的基于IPFS的數(shù)據(jù)存儲(chǔ)和傳輸方案與基于HTTP協(xié)議的傳統(tǒng)數(shù)據(jù)傳輸方案的數(shù)據(jù)傳輸性能進(jìn)行了對(duì)比測試.前者通過go-ipfs提供的命令行工具進(jìn)行測試.本文在Node5上用Apachehttpd 2.4.41構(gòu)建了一個(gè)HTTP服務(wù)器來提供下載服務(wù),其他節(jié)點(diǎn)使用GNU Wget從HTTP服務(wù)器下載文件來測試后者的數(shù)據(jù)傳輸性能.測試分為兩組:單點(diǎn)傳輸性能測試和多點(diǎn)傳輸性能測試.

      4.3.1 單點(diǎn)數(shù)據(jù)傳輸性能測試

      單點(diǎn)數(shù)據(jù)傳輸性能測試在6個(gè)節(jié)點(diǎn)上運(yùn)行,其中Node 5作為上傳節(jié)點(diǎn),Node 1、2、3、4和6作為下載節(jié)點(diǎn).首先測試了基于IPFS的方案的傳輸性能.Node 5將不同大小的文件上傳到IPFS網(wǎng)絡(luò),然后其他節(jié)點(diǎn)依次從IPFS網(wǎng)絡(luò)下載文件.然后測試了基于HTTP協(xié)議的數(shù)據(jù)傳輸性能.使用SCP命令將文件從其他節(jié)點(diǎn)上傳到Node 5,模擬傳統(tǒng)文件共享方案將文件上傳到第三方云服務(wù)器的過程,其他節(jié)點(diǎn)使用GNU Wget依次從Node 5下載文件.記錄了這兩種方案的上傳和下載時(shí)間,以衡量它們的傳輸性能.

      圖4顯示了在不同數(shù)據(jù)大小下的上傳性能測試結(jié)果.圖5顯示了不同數(shù)據(jù)大小下的每個(gè)節(jié)點(diǎn)的下載性能測試結(jié)果.測試結(jié)果表明,本文采用的基于IPFS的方案在上傳性能上優(yōu)于基于HTTP協(xié)議的方案;然而,就單點(diǎn)下載性能而言,基于IPFS的方案比基于HTTP協(xié)議的方案慢.

      4.3.2 多點(diǎn)數(shù)據(jù)傳輸性能測試

      本文在10個(gè)節(jié)點(diǎn)上運(yùn)行多點(diǎn)數(shù)據(jù)傳輸性能測試,其中Node 5作為上傳節(jié)點(diǎn),Node 1、2、3、4、6、7、8、9、10作為下載節(jié)點(diǎn).首先測試了本文采用的基于IPFS的方案的多點(diǎn)下載性能.Node 5將不同大小的文件上傳到IPFS網(wǎng)絡(luò),其他節(jié)點(diǎn)通過Shell腳本并行從IPFS網(wǎng)絡(luò)下載.然后測試了基于HTTP協(xié)議的數(shù)據(jù)下載性能.使用SCP命令將文件從其他節(jié)點(diǎn)上傳到Node 5,并通過運(yùn)行Shell腳本在其他節(jié)點(diǎn)上通過GNU Wget并行從Node 5服務(wù)器下載文件.

      圖4上傳性能測試Fig.4 Upload performance test

      圖5砂輪軸向截形Fig.5 Axial section of grinding wheel

      圖6數(shù)據(jù)多點(diǎn)下載性能測試Fig.6 Data multi-point download performance test

      圖6顯示了測試期間下載所消耗的時(shí)間.其中在大部分節(jié)點(diǎn)上,本文方案的數(shù)據(jù)下載性能優(yōu)于HTTP方案,在少數(shù)節(jié)點(diǎn)上,HTTP方案的數(shù)據(jù)下載性能略優(yōu)于本文方案.測試結(jié)果表明,在多個(gè)節(jié)點(diǎn)同時(shí)下載的情況下,本文采用的基于IPFS的數(shù)據(jù)數(shù)傳方案的下載性能優(yōu)于基于HTTP的方案.

      5 結(jié)論

      本文針對(duì)當(dāng)前多方數(shù)據(jù)共享方案中存在的數(shù)據(jù)中心化問題和加密性能低下問題,提出了一種基于門限代理重加密技術(shù)和IPFS技術(shù)的去中心化的數(shù)據(jù)共享方案.本方案采用門限代理重加密技術(shù)解決了多方數(shù)據(jù)共享情景下數(shù)據(jù)加密低效的問題,采用IPFS技術(shù)解決了數(shù)據(jù)中心化的問題,實(shí)現(xiàn)了數(shù)據(jù)去中心化存儲(chǔ)和傳輸.實(shí)驗(yàn)結(jié)果顯示,本方案并在多方數(shù)據(jù)共享情景下提高了數(shù)據(jù)加密性能和多點(diǎn)下載的性能.

      猜你喜歡
      公鑰密文解密
      解密“熱脹冷縮”
      一種針對(duì)格基后量子密碼的能量側(cè)信道分析框架
      一種支持動(dòng)態(tài)更新的可排名密文搜索方案
      基于模糊數(shù)學(xué)的通信網(wǎng)絡(luò)密文信息差錯(cuò)恢復(fù)
      解密“一包三改”
      炫詞解密
      一種基于混沌的公鑰加密方案
      HES:一種更小公鑰的同態(tài)加密算法
      SM2橢圓曲線公鑰密碼算法綜述
      云存儲(chǔ)中支持詞頻和用戶喜好的密文模糊檢索
      朝阳市| 拜城县| 沁源县| 金寨县| 英超| 杨浦区| 咸丰县| 琼中| 五指山市| 江孜县| 巴彦县| 鲁甸县| 安庆市| 临沂市| 昌乐县| 资源县| 余江县| 互助| 东安县| 通化县| 于都县| 临清市| 彭州市| 曲周县| 同江市| 安多县| 江川县| 延津县| 阿合奇县| 道孚县| 彩票| 东乡族自治县| 曲阜市| 宜兴市| 徐水县| 内丘县| 鄂温| 西华县| 桦南县| 河间市| 斗六市|