• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆-159  評論-223  文章-30  trackbacks-0
             
            群結構  
              定理1
            :若G為一個循環群,則G內每個滿足ord(α)=s的元素α都是擁有s個元素的循環子群的生成元
              證明
                  

              定理2:若G為一個階為n的有限循環群,g為對應的生成元,則對整除n的每個整數k,G都存在一個唯一的階為k的循環子群H。
                這個子群是由gn/k生成的。H是由G內滿足條件αk=1的元素組成的,且G不存在其它子群
              證明
                 

              推論:從上述兩定理可知有限循環群、子群及生成元的關系如下
                  
              例子:依據上述推論得如下
                  

            生成元判定算法
              輸入:循環群G、某子群的階k  
                1)若k=1,則直接輸出e。否則轉到2)
                2)隨機從G-{e}中選擇一元素x
                3)若xk≠e,則轉回2)。否則若k為素數,則跳到5);若k為合數,則轉到4)  
                4)遍歷整除k的真因子d,若xd=e,則轉回2)    
                5)輸出x
            posted @ 2024-03-20 22:49 春秋十二月 閱讀(626) | 評論 (0)編輯 收藏
            混合線性同余發生器(MLCG)      
                  Xn ≡ αXn-1 + c mod m    0<X0, α, c<m,X0為種子,n=1、2、3...

            定理 如果下列3個條件都滿足,則 MLCG達到滿周期(即周期d=m)
                 (1) (c, m)=1,即 c、m互素
                 (2) 對 m的任一素因子p,有α≡1 mod p
                 (3) 如果4|m,則 α≡1 mod 4
              該定理的證明在參考文獻[2]中證明并用到如下兩個引理:
              引理5 設p為素數,α∈Z+且pα>2,如果 x=1(mod pα),x≠1(mod pα+1);則xp=1(mod pα+1), xp≠1(mod pα+2)
                該引理給出了求一個整數的階的判別方法,是理解MLCG周期等于m的充要條件之關鍵。
                本文闡述為什么p是使xp=1(mod pα+1)成立的最小正整數,以及一般情形m=pw(w≥1)是使xm=1(mod pα+w)成立的最小正整數;為什么前提條件是pα>2。

                ◆ 先論證不存在一個整數1≤b<p使得xb=1(mod pα+1)成立
                   
                ◆ 再證不存在一個整數1≤b<m使得xb=1 (mod pα+w)成立
                   
                
                 ◆ 為什么前提條件是pα>2
                   如果pα=2,x=1(mod 2)且x≠1(mod 22)。令x=1+2q,2 ∤ q。有x2=(1+2q)2=1+4q+4q2,注意到q是奇數,則x2=1(mod22),x2=1(mod23)。故得不到引理的結論

              引理6(改寫的等價形式) 如果 α=1(mod 4),則(αm - 1)/(α - 1)=0(mod m) ,m=2w,w>1
                 其實這里當α=1(mod 2)且α≠1(mod 4),結論也是成立的。比如取α=3,m=16,則 (316 -1)=814 -1=(-15)4 -1=-15×-7×-7 -1=-15×-15 -1=9×-7 -1=0(mod 32),
                 即(316 -1)/(3-1)=0(mod 16)。但只有當α=1(mod 4)時,m才是使結論成立的最小正整數。論證如下
                     

            參考文獻    
                 [1] 現代密碼學第4版 楊波    
                 [2] 混合線性同余發生器的周期分析 張廣強、張小彩
            posted @ 2024-03-12 17:30 春秋十二月 閱讀(1459) | 評論 (0)編輯 收藏
            【定義】設整數N=P×Q,P與Q皆為素數,如果P≡Q≡3 (mod4),則N為一個Blum(布盧姆)數

            【定理】設N為Blum數,N ∤ d,若同余方程x2≡d (mod N)有解,則d的平方根中有一半的Jacobi符號為1,另一半Jacobi符號為-1;且僅有一個平方根為模N的二次剩余
                證明:
                

            【推論】設N為Blum數,N=P×Q,令
                
               證明:
                

            例子由定義知N=21=3×7為Blum數,則相關乘法群、二次剩余子群、Jacobi集合如下
               


            【應用一】
            Blum-Goldwasser公鑰加密
                  
                解密正確性是因為步驟1用到了歐拉定理及求平方根的如下算法,步驟2用到了中國剩余定理

                   
                   從上可得x=s(P+1)/4 mod P或x=P-s(P+1)/4 mod P,因(-1)(P-1)/2等于-1 mod P,故前者為模P的二次剩余。從加密流程可知{s1,s2,...,sn+1}正是模N二次剩余類的子集。
                所以從密文中r=sn+1求它的(p+1)/4次冪、(q+1)/4次冪,迭代n次就得到了s1模p的解、s1模q的解,又因p、q、n在迭代中不變,故用歐拉定理預計算dp mod (p-1)、dq mod (q-1)。
                另一種(不太高效而直接的)解密如下
                   
                另加密與明文異或的那部分實際是偽隨機比特發生器,因為平方模N構成二次剩余類上的單向陷門置換,其最低有效位是核心斷言,故從si+1求出lsb(si)是不可行的。簡單證明如下
                   
                  由于均勻選擇一個種子s0,所以為概率加密,進而由可證明安全定理(每個概率公鑰加密都是多項式安全的,及每個多項式安全的公鑰加密都是語義安全的)知滿足IND-CPA安全性
                易知IND-CCA2安全性是不滿足的,因為敵手可用如下攻擊方法獲取明文:已知目標密文C=(r, m⊕σ1σ2σn),構造新密文C’=(r, m’⊕m⊕σ1σ2σn),將C’發給解密預言機得到m’’,則m=m’’⊕m’
                由于加密產生的r與σ1σ2σn都是偽隨機的,所以密文(r, x⊕σ1σ2σn)的分布是偽隨機的,在目標密文前的解密詢問會得到若干密文與明文對,無論怎么構造一對明文,任選其一加密得到的密文都不可區分。因此IND-CCA1安全性是滿足的

            【應用二】無爪函數/置換構造
                  
                  
                如上構造用到Blum數的上述推論,及基于大整數因子分解的困難假設。這里主要解釋下為什么由兩個Jacobi符號不同的平方根可計算大整數的素因子
                  

            【應用三】偽隨機數發生器
                            Xn+1=Xn2 mod N      n=0、1、2...,X0為種子
                 顯然種子不為1。若為一個非二次剩余,則從X1開始就為二次剩余子群的元素,但最后必回到X1而非X0;若為二次剩余,則為了安全需要考究隨機數數列的周期是否整周期(二次剩余子群的大小減1)。
              下面具體分析周期。先舉例幾個很小的Blum數
                  
                 從上面例子可以發現,由二次剩余子群構成的隨機數數列不一定是整周期的,對于N=33無論種子怎么選,都是整周期4;對于N=57若種子選-8或7則周期為2,選其它則為6。
              現在一般化考慮,什么情況下才產生整周期?論證如下
                   
            posted @ 2024-02-25 23:29 春秋十二月 閱讀(1380) | 評論 (0)編輯 收藏
            經典的復雜性關系 
             P是多項式時間確定型圖靈機可識別的語言類,NP是多項式時間非確定型圖靈機可識別的語言類,NPC表示NP完全問題類,coNP表示NP的補,coNPC表示NPC的補。確定型圖靈機是一種從不選擇移動的特殊的非確定型圖靈機,故自然有P屬于NP

                 
             
             coNP、coNPC的定義之集合表述
                  
             上面頂部的圖有個假設前提是:coNPC不屬于NP,即我們相信NP完全問題的補都不屬于NP。但當P=NP或NP=coNP時,可以發現coNPC屬于NP

             ◆ 
            為什么coNPC屬于coNP?
               

             ◆ 
            為什么NPC 不屬于coNP?
               

             ◆ 
            為什么P屬于coNP?
               

             ◆ 當P=NP時,為什么NP=coNP?
               
             ◆ 當NP=coNP時,為什么NPC=coNPC?
                

             前文的關系演變圖沒考慮多項式空間問題類PS與遞歸問題類(因為那兩個條件不會影響到它們),PS(NPS)是帶多項式空間限制的確定型(非確定型)圖靈機可接受的語言類,但不限制運行時間可能需超多項式或指數時間,在外圍加上PS與遞歸語言類后如下

                 

             ◆ 
            為什么coNP 屬于PS?
               

              用于分析加密
                無論對稱還是公鑰加密,統一設加密運算為E,解密為D。對于正常用戶,E和D皆為DTM(確定性圖靈機);對于敵手,若攻擊對稱加密,則E和D為NTM(非確定性圖靈機),攻擊公鑰則解密為NTM。由于E和D輸入為密鑰和明文或密文,因此DTM和NTM可采用多道/多帶結構。DTM代表P類計算,NTM代表NP類計算,故對于公鑰加密安全保障要求P!=NP,這是一個必要條件。另根據計算理論定理,必有L(NTM)=L(DTM),但是它對應的DTM可能要多花費指數時間,這亦說明破解公鑰的解密是困難的


            零知識復雜性關系
              依據Oded Goldreich的《密碼學基礎》,關系如下

                
             
              相關原文片段引用如下
             
              BPP是可被概率多項式時間圖靈機(即隨機化算法)識別的語言類,IP是所有具有交互證明系統的語言構成的類,等于多項式空間語言類即前文經典復雜性關系中的PS,如下圖所述
             
               SZK!=CZK是因為計算不可分辨不一定能推出統計不可分辨,BPP!=PZK之原因可理解為BPP是退化的特殊的完備交互證明系統(證明者什么都不做,僅由驗證者概率性地決定是否接受或拒絕)。
             當(非均勻)單向函數存在時CZK=IP,涉及的命題與定理如下
             

              



             也就是說PS類中的每種語言都具有零知識證明系統,比如NP有如下構造
             
            posted @ 2024-02-09 22:19 春秋十二月 閱讀(1077) | 評論 (0)編輯 收藏

            【定理】設多項式,其中q是某個素數的方冪,Fq為有限域,則    

                       

            是置換多項式,則


            【證明】

                     

            posted @ 2023-12-16 21:49 春秋十二月 閱讀(212) | 評論 (0)編輯 收藏
            周知內聯是為了消除函數調用的代價,即四大指令序列:調用前序列、被調者起始序列、被調者收尾序列、返回后序列。它們通常對應到體系結構調用者保存/恢復寄存器集合與被調者保存/恢復寄存器集合之約束。這個本質也是內聯的前提。試問如果有某體系結構比如S,它任意深度的函數調用代價幾乎為零,那么顯然內聯是沒意義沒必要的。但是S可能存在嗎?我認為不太可能。因為機器的資源比如寄存器集數量與堆棧空間是有限的,且調用需要知曉上下文,所以不能夠支持任意深度的調用,但是可以支持有限深度比如4層調用,這4層調用代價幾乎為零,假設再來一層,那么第5層調用代價就不為零了,這時如果內聯第5層就變成4層調用,代價又幾乎為零。綜上所述,內聯無論在何種體系結構,即使在一定深度內沒意義也不會破壞性能。

            體系結構直接影響程序性能。主要體現在指令集、寄存器、cache三塊。它們對于編譯器實現代碼優化必須都考慮,尤其cache比如內聯優化、循環展開、基本塊布局、函數重排,如果不是因為有cache這玩意,內聯優化的復雜性會大為降低,因為不用考慮代碼膨脹引起的副作用即cache缺失,只要評估函數的指令數與動態執行消耗的關系,指令數很少但執行耗費很多時鐘周期的,則不宜內聯,尤其函數為非葉子結點;指令數很多但執行耗費較少的,則可僅內聯其中的快速路徑代碼。因現實存在cache這玩意,就必須權衡代碼膨脹帶來的副作用,是否能接受一定的膨脹,需要精確評估,構建函數調用頻率與其靜態調用位置的矩陣,計算收益比如平均執行一次的耗時是否減少,若收益為正且明顯則可內聯,否則不宜內聯。

            有些編譯器為了簡單處理,不會內聯帶靜態變量的函數哪怕指令數很少,或者內聯不太正確比如LLVM(詳見下文)。其實單從技術上可以做到,不過要復雜些,復雜在于鏈接器的協作。為了保證函數級靜態變量的語義,編譯時要預留全局唯一標志與構造函數的占位符,在調用者體內插入對全局唯一標志的(位)判斷(標志字的一位對應一個靜態變量,表明是否已構造或初始化賦值)、構造函數調用/初始化賦值、置位標志,而鏈接時要確定全局唯一標志及構造函數的地址。靜態變量、全局唯一標志放于可執行文件的數據區,全局唯一構造/初始化及析構函數放于代碼區,具體布局位置可以靈活,比如. data. static_obj,. text. obj. ctor/dtor。如果這種函數性能影響較大需要內聯優化,而編譯器不支持,有個替代的辦法是用全局變量或文件/類級別的靜態變量,輔以對應標志處理一次性構造或初始化賦值(必要時將這處理封裝為一個函數以確保目標函數被內聯),可達到同樣效果不足之處是作用域擴大了。

            關于LLVM對于帶靜態變量的函數之內聯的測驗結果












            posted @ 2023-11-16 23:32 春秋十二月 閱讀(252) | 評論 (0)編輯 收藏
            談兩個問題:高性能與安全性

            先談高性能:這里指代碼實現層面(非數學優化層面),使用寄存器優化,即主密鑰/輪密鑰、敏感數據比如中間/臨時變量必須存于寄存器,明文/密文放在內存(若有夠用的寄存器則放寄存器),主密鑰用特權寄存器(為支持長期存儲,比如調試寄存器、MSR寄存器),輪密鑰和敏感數據用通用寄存器。那么怎么做?穩妥快捷的方法是用匯編或內聯匯編,手工編排寄存器即構建密鑰與敏感數據到寄存器集合的映射,若用普通的匯編指令,則寄存器的映射比較自由;若用專用的加密指令,則映射相對受限。如果用高級語言比如c/c++開發,問題在于register關鍵字非強制生效,即使強制的,編譯器優化(比如公共子表達式消除)產生的中間變量及寄存器分配策略不完全可控,需要修改編譯器比如LLVM強制某些變量必須分配(特定的)寄存器,為通用性要從編程語言語法屬性到目標機器代碼生成都改動支持,這個方法實現成本有點大。下面是摘自LLVM X86RegisterInfo.td的部分寄存器
              1 // 32-bit registers
              2 let SubRegIndices = [sub_16bit, sub_16bit_hi], CoveredBySubRegs = 1 in {
              3 def EAX : X86Reg<"eax", 0, [AX, HAX]>, DwarfRegNum<[-2, 0, 0]>;
              4 def EDX : X86Reg<"edx", 2, [DX, HDX]>, DwarfRegNum<[-2, 2, 2]>;
              5 def ECX : X86Reg<"ecx", 1, [CX, HCX]>, DwarfRegNum<[-2, 1, 1]>;
              6 def EBX : X86Reg<"ebx", 3, [BX, HBX]>, DwarfRegNum<[-2, 3, 3]>;
              7 def ESI : X86Reg<"esi", 6, [SI, HSI]>, DwarfRegNum<[-2, 6, 6]>;
              8 def EDI : X86Reg<"edi", 7, [DI, HDI]>, DwarfRegNum<[-2, 7, 7]>;
              9 def EBP : X86Reg<"ebp", 5, [BP, HBP]>, DwarfRegNum<[-2, 4, 5]>;
             10 def ESP : X86Reg<"esp", 4, [SP, HSP]>, DwarfRegNum<[-2, 5, 4]>;
             11 def EIP : X86Reg<"eip", 0, [IP, HIP]>, DwarfRegNum<[-2, 8, 8]>;
             12 }
             13 
             14 // X86-64 only, requires REX
             15 let SubRegIndices = [sub_16bit, sub_16bit_hi], CoveredBySubRegs = 1 in {
             16 def R8D  : X86Reg<"r8d",   8, [R8W,R8WH]>;
             17 def R9D  : X86Reg<"r9d",   9, [R9W,R9WH]>;
             18 def R10D : X86Reg<"r10d", 10, [R10W,R10WH]>;
             19 def R11D : X86Reg<"r11d", 11, [R11W,R11WH]>;
             20 def R12D : X86Reg<"r12d", 12, [R12W,R12WH]>;
             21 def R13D : X86Reg<"r13d", 13, [R13W,R13WH]>;
             22 def R14D : X86Reg<"r14d", 14, [R14W,R14WH]>;
             23 def R15D : X86Reg<"r15d", 15, [R15W,R15WH]>;
             24 }
             25 
             26 // 64-bit registers, X86-64 only
             27 let SubRegIndices = [sub_32bit] in {
             28 def RAX : X86Reg<"rax", 0, [EAX]>, DwarfRegNum<[0, -2, -2]>;
             29 def RDX : X86Reg<"rdx", 2, [EDX]>, DwarfRegNum<[1, -2, -2]>;
             30 def RCX : X86Reg<"rcx", 1, [ECX]>, DwarfRegNum<[2, -2, -2]>;
             31 def RBX : X86Reg<"rbx", 3, [EBX]>, DwarfRegNum<[3, -2, -2]>;
             32 def RSI : X86Reg<"rsi", 6, [ESI]>, DwarfRegNum<[4, -2, -2]>;
             33 def RDI : X86Reg<"rdi", 7, [EDI]>, DwarfRegNum<[5, -2, -2]>;
             34 def RBP : X86Reg<"rbp", 5, [EBP]>, DwarfRegNum<[6, -2, -2]>;
             35 def RSP : X86Reg<"rsp", 4, [ESP]>, DwarfRegNum<[7, -2, -2]>;
             36 
             37 // These also require REX.
             38 def R8  : X86Reg<"r8",   8, [R8D]>,  DwarfRegNum<[ 8, -2, -2]>;
             39 def R9  : X86Reg<"r9",   9, [R9D]>,  DwarfRegNum<[ 9, -2, -2]>;
             40 def R10 : X86Reg<"r10", 10, [R10D]>, DwarfRegNum<[10, -2, -2]>;
             41 def R11 : X86Reg<"r11", 11, [R11D]>, DwarfRegNum<[11, -2, -2]>;
             42 def R12 : X86Reg<"r12", 12, [R12D]>, DwarfRegNum<[12, -2, -2]>;
             43 def R13 : X86Reg<"r13", 13, [R13D]>, DwarfRegNum<[13, -2, -2]>;
             44 def R14 : X86Reg<"r14", 14, [R14D]>, DwarfRegNum<[14, -2, -2]>;
             45 def R15 : X86Reg<"r15", 15, [R15D]>, DwarfRegNum<[15, -2, -2]>;
             46 def RIP : X86Reg<"rip",  0, [EIP]>,  DwarfRegNum<[16, -2, -2]>;
             47 }
             48 
             49 // XMM Registers, used by the various SSE instruction set extensions.
             50 def XMM0: X86Reg<"xmm0", 0>, DwarfRegNum<[17, 21, 21]>;
             51 def XMM1: X86Reg<"xmm1", 1>, DwarfRegNum<[18, 22, 22]>;
             52 def XMM2: X86Reg<"xmm2", 2>, DwarfRegNum<[19, 23, 23]>;
             53 def XMM3: X86Reg<"xmm3", 3>, DwarfRegNum<[20, 24, 24]>;
             54 def XMM4: X86Reg<"xmm4", 4>, DwarfRegNum<[21, 25, 25]>;
             55 def XMM5: X86Reg<"xmm5", 5>, DwarfRegNum<[22, 26, 26]>;
             56 def XMM6: X86Reg<"xmm6", 6>, DwarfRegNum<[23, 27, 27]>;
             57 def XMM7: X86Reg<"xmm7", 7>, DwarfRegNum<[24, 28, 28]>;
             58 
             59 // X86-64 only
             60 def XMM8:  X86Reg<"xmm8",   8>, DwarfRegNum<[25, -2, -2]>;
             61 def XMM9:  X86Reg<"xmm9",   9>, DwarfRegNum<[26, -2, -2]>;
             62 def XMM10: X86Reg<"xmm10", 10>, DwarfRegNum<[27, -2, -2]>;
             63 def XMM11: X86Reg<"xmm11", 11>, DwarfRegNum<[28, -2, -2]>;
             64 def XMM12: X86Reg<"xmm12", 12>, DwarfRegNum<[29, -2, -2]>;
             65 def XMM13: X86Reg<"xmm13", 13>, DwarfRegNum<[30, -2, -2]>;
             66 def XMM14: X86Reg<"xmm14", 14>, DwarfRegNum<[31, -2, -2]>;
             67 def XMM15: X86Reg<"xmm15", 15>, DwarfRegNum<[32, -2, -2]>;
             68 
             69 def XMM16:  X86Reg<"xmm16", 16>, DwarfRegNum<[67, -2, -2]>;
             70 def XMM17:  X86Reg<"xmm17", 17>, DwarfRegNum<[68, -2, -2]>;
             71 def XMM18:  X86Reg<"xmm18", 18>, DwarfRegNum<[69, -2, -2]>;
             72 def XMM19:  X86Reg<"xmm19", 19>, DwarfRegNum<[70, -2, -2]>;
             73 def XMM20:  X86Reg<"xmm20", 20>, DwarfRegNum<[71, -2, -2]>;
             74 def XMM21:  X86Reg<"xmm21", 21>, DwarfRegNum<[72, -2, -2]>;
             75 def XMM22:  X86Reg<"xmm22", 22>, DwarfRegNum<[73, -2, -2]>;
             76 def XMM23:  X86Reg<"xmm23", 23>, DwarfRegNum<[74, -2, -2]>;
             77 def XMM24:  X86Reg<"xmm24", 24>, DwarfRegNum<[75, -2, -2]>;
             78 def XMM25:  X86Reg<"xmm25", 25>, DwarfRegNum<[76, -2, -2]>;
             79 def XMM26:  X86Reg<"xmm26", 26>, DwarfRegNum<[77, -2, -2]>;
             80 def XMM27:  X86Reg<"xmm27", 27>, DwarfRegNum<[78, -2, -2]>;
             81 def XMM28:  X86Reg<"xmm28", 28>, DwarfRegNum<[79, -2, -2]>;
             82 def XMM29:  X86Reg<"xmm29", 29>, DwarfRegNum<[80, -2, -2]>;
             83 def XMM30:  X86Reg<"xmm30", 30>, DwarfRegNum<[81, -2, -2]>;
             84 def XMM31:  X86Reg<"xmm31", 31>, DwarfRegNum<[82, -2, -2]>;
             85 
             86 // YMM0-15 registers, used by AVX instructions and
             87 // YMM16-31 registers, used by AVX-512 instructions.
             88 let SubRegIndices = [sub_xmm] in {
             89   foreach  Index = 0-31 in {
             90     def YMM#Index : X86Reg<"ymm"#Index, Index, [!cast("XMM"#Index)]>,
             91                     DwarfRegAlias("XMM"#Index)>;
             92   }
             93 }
             94 
             95 // ZMM Registers, used by AVX-512 instructions.
             96 let SubRegIndices = [sub_ymm] in {
             97   foreach  Index = 0-31 in {
             98     def ZMM#Index : X86Reg<"zmm"#Index, Index, [!cast("YMM"#Index)]>,
             99                     DwarfRegAlias("XMM"#Index)>;
            100   }
            101 }
            102 
            103 // Debug registers
            104 def DR0  : X86Reg<"dr0",   0>;
            105 def DR1  : X86Reg<"dr1",   1>;
            106 def DR2  : X86Reg<"dr2",   2>;
            107 def DR3  : X86Reg<"dr3",   3>;
            108 def DR4  : X86Reg<"dr4",   4>;
            109 def DR5  : X86Reg<"dr5",   5>;
            110 def DR6  : X86Reg<"dr6",   6>;
            111 def DR7  : X86Reg<"dr7",   7>;
            112 def DR8  : X86Reg<"dr8",   8>;
            113 def DR9  : X86Reg<"dr9",   9>;
            114 def DR10 : X86Reg<"dr10", 10>;
            115 def DR11 : X86Reg<"dr11", 11>;
            116 def DR12 : X86Reg<"dr12", 12>;
            117 def DR13 : X86Reg<"dr13", 13>;
            118 def DR14 : X86Reg<"dr14", 14>;
            119 def DR15 : X86Reg<"dr15", 15>;
            120 
            121 def GR32 : RegisterClass<"X86", [i32], 32,
            122                          (add EAX, ECX, EDX, ESI, EDI, EBX, EBP, ESP,
            123                               R8D, R9D, R10D, R11D, R14D, R15D, R12D, R13D)>;
            124 
            125 // GR64 - 64-bit GPRs. This oddly includes RIP, which isn't accurate, since
            126 // RIP isn't really a register and it can't be used anywhere except in an
            127 // address, but it doesn't cause trouble.
            128 // FIXME: it *does* cause trouble - CheckBaseRegAndIndexReg() has extra
            129 // tests because of the inclusion of RIP in this register class.
            130 def GR64 : RegisterClass<"X86", [i64], 64,
            131                          (add RAX, RCX, RDX, RSI, RDI, R8, R9, R10, R11,
            132                               RBX, R14, R15, R12, R13, RBP, RSP, RIP)>;

            再談安全性
            :為保障安全就復雜了,由于密鑰及敏感數據存于寄存器,首先要防止寄存器交換/拷貝到內存(為避免讀取內存的冷啟動攻擊、基于cache的側信道攻擊)的一切可能因素,比如進程調度、由信號或異步中斷引起的處理器模式切換、系統休眠,如果在用戶態實現加解密,就避免不了被調度或切換,因為單核上不可能只運行加解密進程,所以得實現在內核態。這樣一來就要在加解密中禁止搶占與中斷,考慮到系統響應,禁止的粒度不能過大最小為一個分組,分組加解密前禁止搶占與中斷(比如調用linux內核接口preempt_disablelocal_irq_save),解除禁止(比如調用linux內核接口preempt_enablelocal_irq_restore)前必須清零寄存器。在系統休眠時,禁止寄存器復制到內存,休眠恢復時在所有用戶態進程恢復前執行密鑰初始化,同理系統啟動時的密鑰初始化也得在用戶態進程運行前執行。其次要防止其它用戶態進程/內核線程/中斷服務程序讀寫寄存器尤其特權寄存器(為避免用戶態或內核態rootkit),所以要修改內核,過濾相關系統調用比如linux的ptrace,過濾相關內核函數比如linux的native_set_debugreg/native_get_debugreg。對于不可屏蔽的中斷靠禁止是無效的,只能修改中斷處理程序避免寄存器中的密鑰數據被擴散到內存,比如在中斷處理函數入口處清零相關寄存器。綜上基于已知代碼修改的防御不能防御惡意加載/修改代碼之類的攻擊,比如動態安裝的內核模塊/驅動,但可有效防御冷啟動攻擊、只讀DMA攻擊、基于cache的側信道攻擊、用戶態權限的軟件攻擊、內核態的僅運行已有代碼的軟件攻擊
            posted @ 2023-11-09 16:39 春秋十二月 閱讀(4551) | 評論 (0)編輯 收藏




















            posted @ 2023-10-24 15:25 春秋十二月 閱讀(195) | 評論 (0)編輯 收藏
            ​1. 區間圖:用于局部寄存器分配,基本塊內的每個活躍范圍看作一個區間(最早定義位置+最新使用位置),所有活躍范圍構成區間圖。區間圖是一種不精確的沖突圖(因為高估了活躍范圍的范圍而導致偽沖突,比如認為一個復制操作連接的或兩個源相同目標不同的復制操作產生重疊的兩個活躍范圍沖突,但實際沒有沖突),優勢在于著色是P(復雜度O(|V|)或O(|E|))而非NP問題。llvm早期的線性掃描分配器是基于區間圖在全局的擴展,比較適用于JIT編譯(減少編譯時間)
            ​2. 一般圖:用于全局寄存器分配,是一種精確的沖突圖(由一組定義與一組使用構成的網絡)。優勢在于努力最小化溢出活躍范圍而生成高效執行的代碼,但會犧牲編譯時間。llvm的greedy寄存器分配是基于一般圖的代表。編譯器使用的沖突圖可能會將機器約束條件比如多寄存器值/調用約定編碼進去而存在重復邊,導致不滿足圖論中的簡單圖定義,故這里采用一般圖
            ​3. 弦圖:定義詳見https://oi-wiki.org/graph/chord。基于靜態單賦值形式名建立的沖突圖是弦圖。優勢在于可以做到最佳著色(復雜度O(|V|+|E|))而非啟發式(基于一般圖的全局寄存器分配使用啟發式),利于減少寄存器壓力。劣勢在于必須將指派寄存器后的仍然為靜態單賦值代碼轉換為機器碼,而這種轉換可能增加寄存器壓力,以及插入一些可能非必要的復制操作,若復制操作實現的數據流與ssa phi函數對應,則分配器無法合并這種復制,這將破壞弦圖的性質
            ​4. 沖突圖拆分:查找其中的團分割即連通子圖,移除它劃分得到不相交的一些子圖,這樣一來,各子圖可獨立著色(有點類似活躍范圍拆分)而利于減少寄存器壓力,另外實現上還能節省下三角布爾矩陣(用于快速判斷兩結點是否沖突)的規模
            ​#############################
            寄存器分配與圖論的染色理論相關。其它的比如常量傳播與格代數及不動點相關,循環優化與多面體、矩陣相關。這三方面是我目前看到的編譯器所用數學理論
            posted @ 2023-10-04 13:08 春秋十二月 閱讀(3848) | 評論 (0)編輯 收藏



            posted @ 2023-09-30 08:47 春秋十二月 閱讀(96) | 評論 (0)編輯 收藏
            僅列出標題
            共16頁: 1 2 3 4 5 6 7 8 9 Last 
            无码日韩人妻精品久久蜜桃 | 久久九九亚洲精品| 国产精品久久久天天影视| 成人久久精品一区二区三区| 日本福利片国产午夜久久| 久久se这里只有精品| 无码国内精品久久综合88| 久久精品国产精品亚洲毛片| 精品久久久久久无码国产| 思思久久精品在热线热| 99国产欧美精品久久久蜜芽| 久久久久国产成人精品亚洲午夜| 久久亚洲精品无码aⅴ大香| www性久久久com| 一本久久综合亚洲鲁鲁五月天| 国内精品九九久久精品 | 日产精品99久久久久久| 久久99国产精品久久99| 中文字幕精品久久| 精品综合久久久久久888蜜芽| 久久精品一区二区影院| 久久久久人妻精品一区二区三区| 国产呻吟久久久久久久92| 人妻久久久一区二区三区| 久久精品中文字幕有码| 精品综合久久久久久888蜜芽| 久久久久99精品成人片牛牛影视| 天天躁日日躁狠狠久久| 热久久国产欧美一区二区精品| 国产精品无码久久综合| 久久人人爽人人爽人人av东京热| 欧美久久综合性欧美| 蜜臀久久99精品久久久久久小说| 久久香蕉国产线看观看猫咪?v| 国产亚洲欧美精品久久久| 国产精品久久久久久五月尺| 99久久精品这里只有精品| 99国产精品久久| 久久久久久久97| 人妻少妇久久中文字幕 | 久久只这里是精品66|