演算法加密特點:每次加密的結果都不同，但解密的結果都相同，而且都是加密後的資料:
code
--加密演算法:ssource是加密的字元竄
--int
iflag
=1是加密 2是解密
public
static
string
pword(
string
ssource,
intiflag)
else
ls_code
=ls_code
+ls_i;
}random rdm3
=new
random(
~unchecked
((int
)datetime.now.ticks));
intrand1 =(
int)(rdm3.nextdouble()*9
);if
(rand1 ==0
)rand1 =1
;ls_code=((
char
)(rand1*10
+li_head+40
)).tostring()
+ls_code;
}else
else
ls_code
=ls_code
+ls_i;}}
return
ls_code;
}對於該加密演算法的使用方法:
該加密演算法的特點是無論加密多少次但每次解密的結果都是一致的，有個缺點是每次無論加密和解密都需要明文，當前我們對使用者登陸的使用者名稱和密碼進行加密來驗證使用者身份:
在username中輸入使用者名稱(密碼簡化主要演示這個演算法的用法)，當點選加密時顯示加密和解密後的資料，
第一次加密結果:
第二次加密結果:
從上面可以看出加密都是相同的資料chenkai,顯示的加密結果不同，但解密的資料始終相同。
code
--author:chenkai time:2023年3月3日14:33:
40--
button1點選加密的觸發事件方法
protected
void
button1_click(
object
sender, eventargs e)
--從上面看出加密和解密傳入的是encrytstring(chenkai),既都需要明文傳入
當使用者登陸時需要向伺服器端傳入資料和資料庫進行比對，為了保證資料傳輸的安全性對明文資料進行該演算法加密，相對而言資料庫如何設計?
如果我們資料庫中儲存的是加密後的資料，這樣的話因為每次使用者登陸加密的結果都不相同，雖然保證資料安全但無法驗證使用者的身份。這種方案行不通
在則資料庫中儲存的是解密的資料，我們在使用者註冊時把使用者登陸的使用者名稱進行解密處理並存入資料庫，根據該演算法特點無論怎麼加密而解密結果始終是一至的，那麼使用者在註冊後多次登陸中對使用者名稱進行解密並與資料庫進行比對，來判斷使用者身份，這種方案似乎能夠行得通。但這點恰恰就暴露這個演算法的缺點，解密時需要明文，那麼從客戶端傳來的是加密後的資料而非明文，這種方案也沒有用 。該如何更好利用該演算法呢？
我們可以這樣設計資料庫來利用該演算法：
在資料庫中存入的是明文，那麼當使用者登陸時有兩種資料加密和解密 都是非明文，如何選擇呢？上面的兩種方法都選擇是加密資料，死胡同一條，如果我們換乙個角度換成解密資料傳輸到伺服器端於資料庫進行比對，而資料庫儲存的是明文對它進行解密處理，再同客戶端傳來的使用者登陸解密資料進行比對來判斷使用者身份，在傳輸中是非明文而且還能驗證客戶端使用者身份，這種方案能夠行得通。
呵呵繞了大半天，當然這個演算法設計不太好(不是很實用)，但如果想用到還是有辦法的。
對稱加密演算法 DES加密演算法
一 對稱加密演算法 對稱加密也稱為常規加密 私鑰或單鑰加密。乙個對稱加密由5部分組成 明文 plaintext 這是原始資訊或資料，作為演算法的輸入。加密演算法 encryption algorithm 加密演算法對明文進行各種替換和轉換。金鑰 secret key 金鑰也是演算法的輸入。演算法進行...
gentry同態加密演算法 同態加密演算法
本文對同態加密演算法進行學習。參考文章同態加密演算法。定義同態加密演算法保證對聯合密文的解密結果等價於聯合明文。若存在同態加密演算法f，針對明文a和b，加密後分別得到a f a b f b 將其和a b 解密後得到a b，則同態加密演算法f被成為加法同態加密演算法。加法同態演算法的加密和解密分別用e...
對稱加密演算法 非對稱加密演算法
對稱加密演算法 對稱加密演算法是應用較早的加密演算法，技術成熟。在對稱加密演算法中，資料發信方將明文 原始資料 和加密金鑰一起經過特殊加密演算法處理後，使其變成複雜的加密密文傳送出去。收信方收到密文後，若想解讀原文，則需要使用加密用過的金鑰及相同演算法的逆演算法對密文進行解密，才能使其恢復成可讀明文...