哪種加密演算法完全禁用

㈠ ssl安全 怎麼禁用RC4加密演算法

SCHANNEL\Protocols 子項
協議 的注冊表項下 SCHANNEL
鍵用於的控制項使用的協議支持由 Schannel.dll 文件，並限制該協議使用 TLS 伺服器或 TLS 的客戶端。

若要禁止使用的 SSL
3.0 或 TLS 1.0 之外的其他協議，請將 Enabled 值的 DWORD 鍊兼暟鎹改為 0x0 中下面的注冊表項，在 協議 鍵下的每個：

目前的 Microsoft 消息隊列使用的客戶端和伺服器之間只有 PCT 1.0

SCHANNEL\Ciphers 子項

密碼 的注冊表項下 SCHANNEL 鍵用於控制如 DES 或 RC4
對稱演算法的使用。 以下是在 密碼 鍵下的有效注冊表項。

SCHANNEL\Ciphers\RC4
128/128 子項:

rc4 128/128

此子項是指 128 位 RC4。

要允許此密碼演算法、 0xffffffff 到更改
啟用 值的 DWORD 值數據，否則更改為 0x0 的 DWORD
值數據。 如果不配置 啟用 值，啟用了默認值。 此注冊表項不能應用於不具備 SGC
證書

---------------------------------------------------------------------------------------

des:有好幾種：0xffffffff 到更改 啟用，否則更改為 0x0 ，不配置 啟用
值，啟用了默認值，但有很多不允許禁用的演算法。。。

TLS 1.0 和SSL 3.0
：{}是要在regedit里建的值：

ssl_rsa_export_with_rc4_40_md5
{0x00，0x03}

ssl_rsa_with_rc4_128_md5
{0x00，0x04}

SSL_RSA_WITH_DES_CBC_SHA
{0x00，0x09}

ssl_rsa_with_3des_ede_cbc_sha
{0x00，0x0A}

ssl_rsa_export1024_with_des_cbc_sha
{0x00，0x62}

ssl_rsa_export1024_with_rc4_56_sha
{0x00，0x64}

TLS_RSA_WITH_DES_CBC_SHA
{0x00，0x09}

tls_rsa_with_3des_ede_cbc_sha
{0x00，0x0A}

tls_rsa_export1024_with_des_cbc_sha
{0x00，0x62
tls_rsa_export_with_rc4_40_md5

{0x00，0x03}

tls_rsa_with_rc4_128_md5
{0x00，0x04}

1

。。。。SCHANNEL\Ciphers\Triple
DES 128/128 子項:

三重 DES 168/168

2

。。。。SCHANNEL\Ciphers\RC2 56/56
子項:

DES 56/56

3

SCHANNEL\Hashes\MD5
子項:

md5

=====
例子：
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\MD5]
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes\SHA]
"Enabled"=dword:ffffffff

SCHANNEL\Protocols\PCT 1.0\Client

SCHANNEL\Protocols\PCT 1.0\Server

SCHANNEL\Protocols\SSL 2.0\Client

SCHANNEL\Protocols\SSL 2.0\Server

㈡ 如何禁用的SSLv3在IIS和RC4加密演算法

為一個基於密碼學的安全開發包，OpenSSL提供的功能相當強大和全面，囊括了主要的密碼演算法、常用的密鑰和證書封裝管理功能以及SSL協議，並提供了豐富的應用程序供測試或其它目的使用。
1.對稱加密演算法
OpenSSL一共提供了8種對稱加密演算法，其中7種是分組加密演算法，僅有的一種流加密演算法是RC4。這7種分組加密演算法分別是AES、DES、Blowfish、CAST、IDEA、RC2、RC5，都支持電子密碼本模式（ECB）、加密分組鏈接模式（CBC）、加密反饋模式（CFB）和輸出反饋模式（OFB）四種常用的分組密碼加密模式。其中，AES使用的加密反饋模式（CFB）和輸出反饋模式（OFB）分組長度是128位，其它演算法使用的則是64位。事實上，DES演算法裡面不僅僅是常用的DES演算法，還支持三個密鑰和兩個密鑰3DES演算法。
2.非對稱加密演算法
OpenSSL一共實現了4種非對稱加密演算法，包括DH演算法、RSA演算法、DSA演算法和橢圓曲線演算法（EC）。DH演算法一般用戶密鑰交換。RSA演算法既可以用於密鑰交換，也可以用於數字簽名，當然，如果你能夠忍受其緩慢的速度，那麼也可以用於數據加密。DSA演算法則一般只用於數字簽名。
3.信息摘要演算法
OpenSSL實現了5種信息摘要演算法，分別是MD2、MD5、MDC2、SHA（SHA1）和RIPEMD。SHA演算法事實上包括了SHA和SHA1兩種信息摘要演算法，此外，OpenSSL還實現了DSS標准中規定的兩種信息摘要演算法DSS和DSS1。
4.密鑰和證書管理
密鑰和證書管理是PKI的一個重要組成部分，OpenSSL為之提供了豐富的功能，支持多種標准。
首先，OpenSSL實現了ASN.1的證書和密鑰相關標准，提供了對證書、公鑰、私鑰、證書請求以及CRL等數據對象的DER、PEM和BASE64的編解碼功能。OpenSSL提供了產生各種公開密鑰對和對稱密鑰的方法、函數和應用程序，同時提供了對公鑰和私鑰的DER編解碼功能。並實現了私鑰的PKCS#12和PKCS#8的編解碼功能。OpenSSL在標准中提供了對私鑰的加密保護功能，使得密鑰可以安全地進行存儲和分發。
在此基礎上，OpenSSL實現了對證書的X.509標准編解碼、PKCS#12格式的編解碼以及PKCS#7的編解碼功能。並提供了一種文本資料庫，支持證書的管理功能，包括證書密鑰產生、請求產生、證書簽發、吊銷和驗證等功能。
事實上，OpenSSL提供的CA應用程序就是一個小型的證書管理中心（CA），實現了證書簽發的整個流程和證書管理的大部分機制。
5.SSL和TLS協議
OpenSSL實現了SSL協議的SSLv2和SSLv3，支持了其中絕大部分演算法協議。OpenSSL也實現了TLSv1.0，TLS是SSLv3的標准化版，雖然區別不大，但畢竟有很多細節不盡相同。
雖然已經有眾多的軟體實現了OpenSSL的功能，但是OpenSSL裡面實現的SSL協議能夠讓我們對SSL協議有一個更加清楚的認識，因為至少存在兩點：一是OpenSSL實現的SSL協議是開放源代碼的，我們可以追究SSL協議實現的每一個細節；二是OpenSSL實現的SSL協議是純粹的SSL協議，沒有跟其它協議（如HTTP）協議結合在一起，澄清了SSL協議的本來面目。
6.應用程序
OpenSSL的應用程序已經成為了OpenSSL重要的一個組成部分，其重要性恐怕是OpenSSL的開發者開始沒有想到的。現在OpenSSL的應用中，很多都是基於OpenSSL的應用程序而不是其API的，如OpenCA，就是完全使用OpenSSL的應用程序實現的。OpenSSL的應用程序是基於OpenSSL的密碼演算法庫和SSL協議庫寫成的，所以也是一些非常好的OpenSSL的API使用範例，讀懂所有這些範例，你對OpenSSL的API使用了解就比較全面了，當然，這也是一項鍛煉你的意志力的工作。
OpenSSL的應用程序提供了相對全面的功能，在相當多的人看來，OpenSSL已經為自己做好了一切，不需要再做更多的開發工作了，所以，他們也把這些應用程序成為OpenSSL的指令。OpenSSL的應用程序主要包括密鑰生成、證書管理、格式轉換、數據加密和簽名、SSL測試以及其它輔助配置功能。
7.Engine機制 Engine機制的出現是在OpenSSL的0.9.6版的事情，開始的時候是將普通版本跟支持Engine的版本分開的，到了OpenSSL的0.9.7版，Engine機制集成到了OpenSSL的內核中，成為了OpenSSL不可缺少的一部分。 Engine機制目的是為了使OpenSSL能夠透明地使用第三方提供的軟體加密庫或者硬體加密設備進行加密。OpenSSL的Engine機製成功地達到了這個目的，這使得OpenSSL已經不僅僅使一個加密庫，而是提供了一個通用地加密介面，能夠與絕大部分加密庫或者加密設備協調工作。當然，要使特定加密庫或加密設備更OpenSSL協調工作，需要寫少量的介面代碼，但是這樣的工作量並不大，雖然還是需要一點密碼學的知識。Engine機制的功能跟Windows提供的CSP功能目標是基本相同的。目前，OpenSSL的0.9.7版本支持的內嵌第三方加密設備有8種，包括：CryptoSwift、nCipher、Atalla、Nuron、UBSEC、Aep、SureWare以及IBM 4758 CCA的硬體加密設備。現在還出現了支持PKCS#11介面的Engine介面，支持微軟CryptoAPI的介面也有人進行開發。當然，所有上述Engine介面支持不一定很全面，比如，可能支持其中一兩種公開密鑰演算法。
8.輔助功能
BIO機制是OpenSSL提供的一種高層IO介面，該介面封裝了幾乎所有類型的IO介面，如內存訪問、文件訪問以及Socket等。這使得代碼的重用性大幅度提高，OpenSSL提供API的復雜性也降低了很多。
OpenSSL對於隨機數的生成和管理也提供了一整套的解決方法和支持API函數。隨機數的好壞是決定一個密鑰是否安全的重要前提。
OpenSSL還提供了其它的一些輔助功能，如從口令生成密鑰的API，證書簽發和管理中的配置文件機制等等。如果你有足夠的耐心，將會在深入使用OpenSSL的過程慢慢發現很多這樣的小功能，讓你不斷有新的驚喜。

㈢ 加密基礎知識二 非對稱加密RSA演算法和對稱加密

上述過程中，出現了公鑰(3233,17)和私鑰(3233,2753)，這兩組數字是怎麼找出來的呢？參考 RSA演算法原理（二）
首字母縮寫說明：E是加密（Encryption）D是解密（Decryption）N是數字（Number）。

1.隨機選擇兩個不相等的質數p和q。
alice選擇了61和53。（實際應用中，這兩個質數越大，就越難破解。）

2.計算p和q的乘積n。
n = 61×53 = 3233
n的長度就是密鑰長度。3233寫成二進制是110010100001，一共有12位，所以這個密鑰就是12位。實際應用中，RSA密鑰一般是1024位，重要場合則為2048位。

3.計算n的歐拉函數φ(n)。稱作L
根據公式φ(n) = (p-1)(q-1)
alice算出φ(3233)等於60×52，即3120。

4.隨機選擇一個整數e，也就是公鑰當中用來加密的那個數字
條件是1< e < φ(n)，且e與φ(n) 互質。
alice就在1到3120之間，隨機選擇了17。（實際應用中，常常選擇65537。）

5.計算e對於φ(n)的模反元素d。也就是密鑰當中用來解密的那個數字
所謂"模反元素"就是指有一個整數d，可以使得ed被φ(n)除的余數為1。ed ≡ 1 (mod φ(n))
alice找到了2753，即17*2753 mode 3120 = 1

6.將n和e封裝成公鑰，n和d封裝成私鑰。
在alice的例子中，n=3233，e=17，d=2753，所以公鑰就是 (3233,17)，私鑰就是（3233, 2753）。

上述故事中，blob為了偷偷地傳輸移動位數6，使用了公鑰做加密，即6^17 mode 3233 = 824。alice收到824之後，進行解密，即824^2753 mod 3233 = 6。也就是說，alice成功收到了blob使用的移動位數。

再來復習一下整個流程：
p=17,q=19
n = 17 19 = 323
L = 16 18 = 144
E = 5(E需要滿足以下兩個條件：1<E<144,E和144互質)
D = 29(D要滿足兩個條件，1<D<144,D mode 144 = 1)
假設某個需要傳遞123，則加密後：123^5 mode 323 = 225
接收者收到225後，進行解密，225^ 29 mode 323 = 123

回顧上面的密鑰生成步驟，一共出現六個數字：
p
q
n
L即φ(n)
e
d
這六個數字之中，公鑰用到了兩個（n和e），其餘四個數字都是不公開的。其中最關鍵的是d，因為n和d組成了私鑰，一旦d泄漏，就等於私鑰泄漏。那麼，有無可能在已知n和e的情況下，推導出d？
（1）ed≡1 (mod φ(n))。只有知道e和φ(n)，才能算出d。
（2）φ(n)=(p-1)(q-1)。只有知道p和q，才能算出φ(n)。
（3）n=pq。只有將n因數分解，才能算出p和q。
結論：如果n可以被因數分解，d就可以算出，也就意味著私鑰被破解。
可是，大整數的因數分解，是一件非常困難的事情。目前，除了暴力破解，還沒有發現別的有效方法。維基網路這樣寫道："對極大整數做因數分解的難度決定了RSA演算法的可靠性。換言之，對一極大整數做因數分解愈困難，RSA演算法愈可靠。假如有人找到一種快速因數分解的演算法，那麼RSA的可靠性就會極度下降。但找到這樣的演算法的可能性是非常小的。今天只有短的RSA密鑰才可能被暴力破解。到2008年為止，世界上還沒有任何可靠的攻擊RSA演算法的方式。只要密鑰長度足夠長，用RSA加密的信息實際上是不能被解破的。"

然而，雖然RSA的安全性依賴於大數的因子分解，但並沒有從理論上證明破譯RSA的難度與大數分解難度等價。即RSA的重大缺陷是無法從理論上把握它的保密性能如何。此外，RSA的缺點還有：
A)產生密鑰很麻煩，受到素數產生技術的限制，因而難以做到一次一密。
B)分組長度太大，為保證安全性，n 至少也要 600bits以上，使運算代價很高，尤其是速度較慢，較對稱密碼演算法慢幾個數量級；且隨著大數分解技術的發展，這個長度還在增加，不利於數據格式的標准化。因此， 使用RSA只能加密少量數據，大量的數據加密還要靠對稱密碼演算法 。

加密和解密是自古就有技術了。經常看到偵探電影的橋段，勇敢又機智的主角，拿著一長串毫無意義的數字苦惱，忽然靈光一閃，翻出一本厚書，將第一個數字對應頁碼數，第二個數字對應行數，第三個數字對應那一行的某個詞。數字變成了一串非常有意義的話：
Eat the beancurd with the peanut. Taste like the ham.

這種加密方法是將原來的某種信息按照某個規律打亂。某種打亂的方式就叫做密鑰(cipher code)。發出信息的人根據密鑰來給信息加密，而接收信息的人利用相同的密鑰，來給信息解密。 就好像一個帶鎖的盒子。發送信息的人將信息放到盒子里，用鑰匙鎖上。而接受信息的人則用相同的鑰匙打開。加密和解密用的是同一個密鑰，這種加密稱為對稱加密（symmetric encryption）。

如果一對一的話，那麼兩人需要交換一個密鑰。一對多的話，比如總部和多個特工的通信，依然可以使用同一套密鑰。 但這種情況下，對手偷到一個密鑰的話，就知道所有交流的信息了。 二戰中盟軍的情報戰成果，很多都來自於破獲這種對稱加密的密鑰。

為了更安全，總部需要給每個特工都設計一個不同的密鑰。如果是FBI這樣龐大的機構，恐怕很難維護這么多的密鑰。在現代社會，每個人的信用卡信息都需要加密。一一設計密鑰的話，銀行怕是要跪了。

對稱加密的薄弱之處在於給了太多人的鑰匙。如果只給特工鎖，而總部保有鑰匙，那就容易了。特工將信息用鎖鎖到盒子里，誰也打不開，除非到總部用唯一的一把鑰匙打開。只是這樣的話，特工每次出門都要帶上許多鎖，太容易被識破身份了。總部老大想了想，乾脆就把造鎖的技術公開了。特工，或者任何其它人，可以就地取材，按照圖紙造鎖，但無法根據圖紙造出鑰匙。鑰匙只有總部的那一把。

上面的關鍵是鎖和鑰匙工藝不同。知道了鎖，並不能知道鑰匙。這樣，銀行可以將「造鎖」的方法公布給所有用戶。 每個用戶可以用鎖來加密自己的信用卡信息。即使被別人竊聽到，也不用擔心：只有銀行才有鑰匙呢！這樣一種加密演算法叫做非對稱加密(asymmetric encryption)。非對稱加密的經典演算法是RSA演算法。它來自於數論與計算機計數的奇妙結合。

1976年，兩位美國計算機學家Whitfield Diffie 和 Martin Hellman，提出了一種嶄新構思，可以在不直接傳遞密鑰的情況下，完成解密。這被稱為"Diffie-Hellman密鑰交換演算法"。這個演算法啟發了其他科學家。人們認識到，加密和解密可以使用不同的規則，只要這兩種規則之間存在某種對應關系即可，這樣就避免了直接傳遞密鑰。這種新的加密模式被稱為"非對稱加密演算法"。

1977年，三位數學家Rivest、Shamir 和 Adleman 設計了一種演算法，可以實現非對稱加密。這種演算法用他們三個人的名字命名，叫做RSA演算法。從那時直到現在，RSA演算法一直是最廣為使用的"非對稱加密演算法"。毫不誇張地說，只要有計算機網路的地方，就有RSA演算法。

1.能「撞」上的保險箱（非對稱/公鑰加密體制，Asymmetric / Public Key Encryption）

數據加密解密和門鎖很像。最開始的時候，人們只想到了那種只能用鑰匙「鎖」數據的鎖。如果在自己的電腦上自己加密數據，當然可以用最開始這種門鎖的形式啦，方便快捷，簡單易用有木有。

但是我們現在是通信時代啊，雙方都想做安全的通信怎麼辦呢？如果也用這種方法，通信就好像互相發送密碼保險箱一樣…而且雙方必須都有鑰匙才能進行加密和解密。也就是說，兩個人都拿著保險箱的鑰匙，你把數據放進去，用鑰匙鎖上發給我。我用同樣的鑰匙把保險箱打開，再把我的數據鎖進保險箱，發送給你。

這樣看起來好像沒什麼問題。但是，這裡面 最大的問題是：我們兩個怎麼弄到同一個保險箱的同一個鑰匙呢？ 好像僅有的辦法就是我們兩個一起去買個保險箱，然後一人拿一把鑰匙，以後就用這個保險箱了。可是，現代通信社會，絕大多數情況下別說一起去買保險箱了，連見個面都難，這怎麼辦啊？

於是，人們想到了「撞門」的方法。我這有個可以「撞上」的保險箱，你那裡自己也買一個這樣的保險箱。通信最開始，我把保險箱打開，就這么開著把保險箱發給你。你把數據放進去以後，把保險箱「撞」上發給我。撞上以後，除了我以外，誰都打不開保險箱了。這就是RSA了，公開的保險箱就是公鑰，但是我有私鑰，我才能打開。

2.數字簽名
這種鎖看起來好像很不錯，但是鎖在運輸的過程中有這么一個嚴重的問題：你怎麼確定你收到的開著的保險箱就是我發來的呢？對於一個聰明人，他完全可以這么干：
(a)裝作運輸工人。我現在把我開著的保險箱運給對方。運輸工人自己也弄這么一個保險箱，運輸的時候把保險箱換成他做的。
(b)對方收到保險箱後，沒法知道這個保險箱是我最初發過去的，還是運輸工人替換的。對方把數據放進去，把保險箱撞上。
(c)運輸工人往回運的時候，用自己的鑰匙打開自己的保險箱，把數據拿走。然後復印也好，偽造也好，弄出一份數據，把這份數據放進我的保險箱，撞上，然後發給我。
從我的角度，從對方的角度，都會覺得這數據傳輸過程沒問題。但是，運輸工人成功拿到了數據，整個過程還是不安全的，大概的過程是這樣：

這怎麼辦啊？這個問題的本質原因是，人們沒辦法獲知，保險箱到底是「我」做的，還是運輸工人做的。那乾脆，我們都別做保險箱了，讓權威機構做保險箱，然後在每個保險箱上用特殊的工具刻上一個編號。對方收到保險箱的時候，在權威機構的「公告欄」上查一下編號，要是和保險箱上的編號一樣，我就知道這個保險箱是「我」的，就安心把數據放進去。大概過程是這樣的：

如何做出刻上編號，而且編號沒法修改的保險箱呢？這涉及到了公鑰體制中的另一個問題：數字簽名。
要知道，刻字這種事情吧，誰都能幹，所以想做出只能自己刻字，還沒法讓別人修改的保險箱確實有點難度。那麼怎麼辦呢？這其實困擾了人們很長的時間。直到有一天，人們發現：我們不一定非要在保險箱上刻規規矩矩的字，我們乾脆在保險箱上刻手寫名字好了。而且，刻字有點麻煩，乾脆我們在上面弄張紙，讓人直接在上面寫，簡單不費事。具體做法是，我們在保險箱上嵌進去一張紙，然後每個出產的保險箱都讓權威機構的CEO簽上自己的名字。然後，CEO把自己的簽名公開在權威機構的「公告欄」上面。比如這個CEO就叫「學酥」，那麼整個流程差不多是這個樣子：

這個方法的本質原理是，每個人都能夠通過筆跡看出保險箱上的字是不是學酥CEO簽的。但是呢，這個字體是學酥CEO唯一的字體。別人很難模仿。如果模仿我們就能自己分辨出來了。要是實在分辨不出來呢，我們就請一個筆跡專家來分辨。這不是很好嘛。這個在密碼學上就是數字簽名。

上面這個簽字的方法雖然好，但是還有一個比較蛋疼的問題。因為簽字的樣子是公開的，一個聰明人可以把公開的簽字影印一份，自己造個保險箱，然後把這個影印的字也嵌進去。這樣一來，這個聰明人也可以造一個相同簽字的保險箱了。解決這個問題一個非常簡單的方法就是在看保險箱上的簽名時，不光看字體本身，還要看字體是不是和公開的字體完全一樣。要是完全一樣，就可以考慮這個簽名可能是影印出來的。甚至，還要考察字體是不是和其他保險櫃上的字體一模一樣。因為聰明人為了欺騙大家，可能不影印公開的簽名，而影印其他保險箱上的簽名。這種解決方法雖然簡單，但是驗證簽名的時候麻煩了一些。麻煩的地方在於我不僅需要對比保險箱上的簽名是否與公開的筆跡一樣，還需要對比得到的簽名是否與公開的筆跡完全一樣，乃至是否和所有發布的保險箱上的簽名完全一樣。有沒有什麼更好的方法呢？

當然有，人們想到了一個比較好的方法。那就是，學酥CEO簽字的時候吧，不光把名字簽上，還得帶上簽字得日期，或者帶上這個保險箱的編號。這樣一來，每一個保險箱上的簽字就唯一了，這個簽字是學酥CEO的簽名+學酥CEO寫上的時間或者編號。這樣一來，就算有人偽造，也只能偽造用過的保險箱。這個問題就徹底解決了。這個過程大概是這么個樣子：

3 造價問題（密鑰封裝機制，Key Encapsulation Mechanism）
解決了上面的各種問題，我們要考慮考慮成本了… 這種能「撞」門的保險箱雖然好，但是這種鎖造價一般來說要比普通的鎖要高，而且鎖生產時間也會變長。在密碼學中，對於同樣「結實」的鎖，能「撞」門的鎖的造價一般來說是普通鎖的上千倍。同時，能「撞」門的鎖一般來說只能安裝在小的保險櫃裡面。畢竟，這么復雜的鎖，裝起來很費事啊！而普通鎖安裝在多大的保險櫃上面都可以呢。如果兩個人想傳輸大量數據的話，用一個大的保險櫃比用一堆小的保險櫃慢慢傳要好的多呀。怎麼解決這個問題呢？人們又想出了一個非常棒的方法：我們把兩種鎖結合起來。能「撞」上的保險櫃裡面放一個普通鎖的鑰匙。然後造一個用普通的保險櫃來鎖大量的數據。這樣一來，我們相當於用能「撞」上的保險櫃發一個鑰匙過去。對方收到兩個保險櫃後，先用自己的鑰匙把小保險櫃打開，取出鑰匙。然後在用這個鑰匙開大的保險櫃。這樣做更棒的一個地方在於，既然對方得到了一個鑰匙，後續再通信的時候，我們就不再需要能「撞」上的保險櫃了啊，在以後一定時間內就用普通保險櫃就好了，方便快捷嘛。

以下參考 數字簽名、數字證書、SSL、https是什麼關系？
4.數字簽名（Digital Signature）
數據在瀏覽器和伺服器之間傳輸時，有可能在傳輸過程中被冒充的盜賊把內容替換了，那麼如何保證數據是真實伺服器發送的而不被調包呢，同時如何保證傳輸的數據沒有被人篡改呢，要解決這兩個問題就必須用到數字簽名，數字簽名就如同日常生活的中的簽名一樣，一旦在合同書上落下了你的大名，從法律意義上就確定是你本人簽的字兒，這是任何人都沒法仿造的，因為這是你專有的手跡，任何人是造不出來的。那麼在計算機中的數字簽名怎麼回事呢？數字簽名就是用於驗證傳輸的內容是不是真實伺服器發送的數據，發送的數據有沒有被篡改過，它就干這兩件事，是非對稱加密的一種應用場景。不過他是反過來用私鑰來加密，通過與之配對的公鑰來解密。
第一步：服務端把報文經過Hash處理後生成摘要信息Digest，摘要信息使用私鑰private-key加密之後就生成簽名，伺服器把簽名連同報文一起發送給客戶端。
第二步：客戶端接收到數據後，把簽名提取出來用public-key解密，如果能正常的解密出來Digest2，那麼就能確認是對方發的。
第三步：客戶端把報文Text提取出來做同樣的Hash處理，得到的摘要信息Digest1，再與之前解密出來的Digist2對比，如果兩者相等，就表示內容沒有被篡改，否則內容就是被人改過了。因為只要文本內容哪怕有任何一點點改動都會Hash出一個完全不一樣的摘要信息出來。

5.數字證書（Certificate Authority）
數字證書簡稱CA，它由權威機構給某網站頒發的一種認可憑證，這個憑證是被大家（瀏覽器）所認可的，為什麼需要用數字證書呢，難道有了數字簽名還不夠安全嗎？有這樣一種情況，就是瀏覽器無法確定所有的真實伺服器是不是真的是真實的，舉一個簡單的例子：A廠家給你們家安裝鎖，同時把鑰匙也交給你，只要鑰匙能打開鎖，你就可以確定鑰匙和鎖是配對的，如果有人把鑰匙換了或者把鎖換了，你是打不開門的，你就知道肯定被竊取了，但是如果有人把鎖和鑰匙替換成另一套表面看起來差不多的，但質量差很多的，雖然鑰匙和鎖配套，但是你卻不能確定這是否真的是A廠家給你的，那麼這時候，你可以找質檢部門來檢驗一下，這套鎖是不是真的來自於A廠家，質檢部門是權威機構，他說的話是可以被公眾認可的（呵呵）。
同樣的， 因為如果有人（張三）用自己的公鑰把真實伺服器發送給瀏覽器的公鑰替換了，於是張三用自己的私鑰執行相同的步驟對文本Hash、數字簽名，最後得到的結果都沒什麼問題，但事實上瀏覽器看到的東西卻不是真實伺服器給的，而是被張三從里到外（公鑰到私鑰）換了一通。那麼如何保證你現在使用的公鑰就是真實伺服器發給你的呢？我們就用數字證書來解決這個問題。數字證書一般由數字證書認證機構（Certificate Authority）頒發，證書裡麵包含了真實伺服器的公鑰和網站的一些其他信息，數字證書機構用自己的私鑰加密後發給瀏覽器，瀏覽器使用數字證書機構的公鑰解密後得到真實伺服器的公鑰。這個過程是建立在被大家所認可的證書機構之上得到的公鑰，所以這是一種安全的方式。

常見的對稱加密演算法有DES、3DES、AES、RC5、RC6。非對稱加密演算法應用非常廣泛，如SSH,
HTTPS, TLS，電子證書，電子簽名，電子身份證等等。
參考 DES/3DES/AES區別

㈣ 使用哪種加密協議最安全，如des，3des，aes，blowfifh

對稱加密演算法 對稱加密演算法是應用較早的加密演算法，技術成熟。在對稱加密演算法中，數據發信方將明文（原始數據）和加密密鑰一起經過特殊加密演算法處理後，使其變成復雜的加密密文發送出去。收信方收到密文後，若想解讀原文，則需要使用加密用過的密鑰及相同演算法的逆演算法對密文進行解密，才能使其恢復成可讀明文。在對稱加密演算法中，使用的密鑰只有一個，發收信雙方都使用這個密鑰對數據進行加密和解密，這就要求解密方事先必須知道加密密鑰。對稱加密演算法的特點是演算法公開、計算量小、加密速度快、加密效率高。不足之處是，交易雙方都使用同樣鑰匙，安全性得不到保證。此外，每對用戶每次使用對稱加密演算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量成幾何級數增長，密鑰管理成為用戶的負擔。對稱加密演算法在分布式網路系統上使用較為困難，主要是因為密鑰管理困難，使用成本較高。在計算機專網系統中廣泛使用的對稱加密演算法有DES和IDEA等。美國國家標准局倡導的AES即將作為新標准取代DES。

㈤ ssl安全 怎麼禁用RC4加密演算法

SCHANNEL\Protocols 子項
協議 的注冊表項下 SCHANNEL
鍵用於的控制項使用的協議支持由 Schannel.dll 文件，並限制該協議使用 TLS 伺服器或 TLS 的客戶端。

㈥ 怎麼在伺服器端禁止使用rc4加密演算法

.版本 2.子程序 加密為rc4, 文本型, 公開, 用RC4演算法對文本進行加密.參數 加密的數據, 文本型, , 欲加密的文本.參數 加密密鑰, 文本型, 可空, 用作加密的密碼.局部變數 臨時, 位元組集.局部變數 s, 位元組型, , "256".局部變數 k, 位元組型, , "256"....

㈦ 輕量級 加密演算法 有哪幾種

注:(以下內容我是從網上找的,不知道能不能幫到你..這些問題我也不怎麼懂!!)
1.AES(Advanced Encryption Standard)，
AES是一個使用128為分組塊的分組加密演算法，分組塊和128、192或256位的密鑰一起作為輸入，對4×4的位元組數組上進行操作。AES的每一輪加密都包含4個階段，分別是AddRoundKey，SubBytes，ShiftRows，和MixColumns。眾所周之AES是種十分高效的演算法，尤其在8位架構中，這源於它面向位元組的設計。
AES 適用於8位的小型單片機或者普通的32位微處理器,並且適合用專門的硬體實現，硬體實現能夠使其吞吐量（每秒可以到達的加密/解密bit數）達到十億量級。同樣，其也適用於RFID系統。[3]高效的實現和演算法的免費使用為AES在無線區域網和後來出現的相關協議中的應用鋪平了道路。
2.DESL(Data Encryption Standard Lightweight Extension),
數據加密標准（DES）是由美國聯邦信息處理標准在1976年為美國選出的一種加密演算法。作為一個分組加密演算法，DES在64位大小的分組快上進行操作，其密鑰同樣也是64位。[10]DES的大致結構由Feistel網路組成，此網路中包括含有8個S-Boxes的16次完全相同的基本輪回，一次初始排列，一次最終排列和一個獨立的密鑰次序表。
3.XXTEA
TEA微型加密演算法最初是由David Wheeler和Roger Needham在1994年以Fast Software Encryption工作室的名義發表的，設計的重點在於描述與實現的簡單性。它是一種分組加密演算法，以128位的密鑰對64位的分組塊進行操作。[6]TEA遭受到等效密鑰的困擾——每個密鑰與其他是那個密鑰是等效的，也就是說有效的密鑰長度只有126位。此演算法易受到相關密鑰（Related Key）攻擊法的攻擊。

㈧ 不安全的加密演算法不包括什麼

DES（Data Encryption Standard）：數據加密標准，速度較快，適用於加密大量數據的場合。

3DES（Triple DES）：是基於DES，對一塊數據用三個不同的密鑰進行三次加密，強度更高。

AES（Advanced Encryption Standard）：高級加密標准，是下一代的加密演算法標准，速度快，安全級別高；

演算法原理
AES 演算法基於排列和置換運算。排列是對數據重新進行安排，置換是將一個數據單元替換為另一個。AES 使用幾種不同的方法來執行排列和置換運算。

㈨ 目前讓密碼最安全的演算法是什麼

加密演算法

加密技術是對信息進行編碼和解碼的技術，編碼是把原來可讀信息（又稱明文）譯成代碼形式（又稱密文），其逆過程就是解碼（解密）。加密技術的要點是加密演算法，加密演算法可以分為對稱加密、不對稱加密和不可逆加密三類演算法。

對稱加密演算法 對稱加密演算法是應用較早的加密演算法，技術成熟。在對稱加密演算法中，數據發信方將明文（原始數據）和加密密鑰一起經過特殊加密演算法處理後，使其變成復雜的加密密文發送出去。收信方收到密文後，若想解讀原文，則需要使用加密用過的密鑰及相同演算法的逆演算法對密文進行解密，才能使其恢復成可讀明文。在對稱加密演算法中，使用的密鑰只有一個，發收信雙方都使用這個密鑰對數據進行加密和解密，這就要求解密方事先必須知道加密密鑰。對稱加密演算法的特點是演算法公開、計算量小、加密速度快、加密效率高。不足之處是，交易雙方都使用同樣鑰匙，安全性得不到保證。此外，每對用戶每次使用對稱加密演算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量成幾何級數增長，密鑰管理成為用戶的負擔。對稱加密演算法在分布式網路系統上使用較為困難，主要是因為密鑰管理困難，使用成本較高。在計算機專網系統中廣泛使用的對稱加密演算法有DES和IDEA等。美國國家標准局倡導的AES即將作為新標准取代DES。

不對稱加密演算法 不對稱加密演算法使用兩把完全不同但又是完全匹配的一對鑰匙—公鑰和私鑰。在使用不對稱加密演算法加密文件時，只有使用匹配的一對公鑰和私鑰，才能完成對明文的加密和解密過程。加密明文時採用公鑰加密，解密密文時使用私鑰才能完成，而且發信方（加密者）知道收信方的公鑰，只有收信方（解密者）才是唯一知道自己私鑰的人。不對稱加密演算法的基本原理是，如果發信方想發送只有收信方才能解讀的加密信息，發信方必須首先知道收信方的公鑰，然後利用收信方的公鑰來加密原文；收信方收到加密密文後，使用自己的私鑰才能解密密文。顯然，採用不對稱加密演算法，收發信雙方在通信之前，收信方必須將自己早已隨機生成的公鑰送給發信方，而自己保留私鑰。由於不對稱演算法擁有兩個密鑰，因而特別適用於分布式系統中的數據加密。廣泛應用的不對稱加密演算法有RSA演算法和美國國家標准局提出的DSA。以不對稱加密演算法為基礎的加密技術應用非常廣泛。

不可逆加密演算法 不可逆加密演算法的特徵是加密過程中不需要使用密鑰，輸入明文後由系統直接經過加密演算法處理成密文，這種加密後的數據是無法被解密的，只有重新輸入明文，並再次經過同樣不可逆的加密演算法處理，得到相同的加密密文並被系統重新識別後，才能真正解密。顯然，在這類加密過程中，加密是自己，解密還得是自己，而所謂解密，實際上就是重新加一次密，所應用的「密碼」也就是輸入的明文。不可逆加密演算法不存在密鑰保管和分發問題，非常適合在分布式網路系統上使用，但因加密計算復雜，工作量相當繁重，通常只在數據量有限的情形下使用，如廣泛應用在計算機系統中的口令加密，利用的就是不可逆加密演算法。近年來，隨著計算機系統性能的不斷提高，不可逆加密的應用領域正在逐漸增大。在計算機網路中應用較多不可逆加密演算法的有RSA公司發明的MD5演算法和由美國國家標准局建議的不可逆加密標准SHS(Secure Hash Standard:安全雜亂信息標准)等。

加密技術

加密演算法是加密技術的基礎，任何一種成熟的加密技術都是建立多種加密演算法組合，或者加密演算法和其他應用軟體有機結合的基礎之上的。下面我們介紹幾種在計算機網路應用領域廣泛應用的加密技術。

非否認（Non-repudiation）技術 該技術的核心是不對稱加密演算法的公鑰技術，通過產生一個與用戶認證數據有關的數字簽名來完成。當用戶執行某一交易時，這種簽名能夠保證用戶今後無法否認該交易發生的事實。由於非否認技術的操作過程簡單，而且直接包含在用戶的某類正常的電子交易中，因而成為當前用戶進行電子商務、取得商務信任的重要保證。

PGP（Pretty Good Privacy）技術 PGP技術是一個基於不對稱加密演算法RSA公鑰體系的郵件加密技術，也是一種操作簡單、使用方便、普及程度較高的加密軟體。PGP技術不但可以對電子郵件加密，防止非授權者閱讀信件；還能對電子郵件附加數字簽名，使收信人能明確了解發信人的真實身份；也可以在不需要通過任何保密渠道傳遞密鑰的情況下，使人們安全地進行保密通信。PGP技術創造性地把RSA不對稱加密演算法的方便性和傳統加密體系結合起來，在數字簽名和密鑰認證管理機制方面採用了無縫結合的巧妙設計，使其幾乎成為最為流行的公鑰加密軟體包。

數字簽名（Digital Signature）技術 數字簽名技術是不對稱加密演算法的典型應用。數字簽名的應用過程是，數據源發送方使用自己的私鑰對數據校驗和或其他與數據內容有關的變數進行加密處理，完成對數據的合法「簽名」，數據接收方則利用對方的公鑰來解讀收到的「數字簽名」，並將解讀結果用於對數據完整性的檢驗，以確認簽名的合法性。數字簽名技術是在網路系統虛擬環境中確認身份的重要技術，完全可以代替現實過程中的「親筆簽字」，在技術和法律上有保證。在公鑰與私鑰管理方面，數字簽名應用與加密郵件PGP技術正好相反。在數字簽名應用中，發送者的公鑰可以很方便地得到，但他的私鑰則需要嚴格保密。

PKI（Public Key Infrastructure）技術 PKI技術是一種以不對稱加密技術為核心、可以為網路提供安全服務的公鑰基礎設施。PKI技術最初主要應用在Internet環境中，為復雜的互聯網系統提供統一的身份認證、數據加密和完整性保障機制。由於PKI技術在網路安全領域所表現出的巨大優勢，因而受到銀行、證券、政府等核心應用系統的青睞。PKI技術既是信息安全技術的核心，也是電子商務的關鍵和基礎技術。由於通過網路進行的電子商務、電子政務等活動缺少物理接觸，因而使得利用電子方式驗證信任關系變得至關重要，PKI技術恰好能夠有效解決電子商務應用中的機密性、真實性、完整性、不可否認性和存取控制等安全問題。一個實用的PKI體系還必須充分考慮互操作性和可擴展性。PKI體系所包含的認證中心（CA）、注冊中心（RA）、策略管理、密鑰與證書管理、密鑰備份與恢復、撤銷系統等功能模塊應該有機地結合在一起。

加密的未來趨勢

盡管雙鑰密碼體制比單鑰密碼體制更為可靠，但由於計算過於復雜，雙鑰密碼體制在進行大信息量通信時，加密速率僅為單鑰體制的1/100，甚至是1/1000。正是由於不同體制的加密演算法各有所長，所以在今後相當長的一段時期內，各類加密體制將會共同發展。而在由IBM等公司於1996年聯合推出的用於電子商務的協議標准SET（Secure Electronic Transaction）中和1992年由多國聯合開發的PGP技術中，均採用了包含單鑰密碼、雙鑰密碼、單向雜湊演算法和隨機數生成演算法在內的混合密碼系統的動向來看，這似乎從一個側面展示了今後密碼技術應用的未來。

在單鑰密碼領域，一次一密被認為是最為可靠的機制，但是由於流密碼體制中的密鑰流生成器在演算法上未能突破有限循環，故一直未被廣泛應用。如果找到一個在演算法上接近無限循環的密鑰流生成器，該體制將會有一個質的飛躍。近年來，混沌學理論的研究給在這一方向產生突破帶來了曙光。此外，充滿生氣的量子密碼被認為是一個潛在的發展方向，因為它是基於光學和量子力學理論的。該理論對於在光纖通信中加強信息安全、對付擁有量子計算能力的破譯無疑是一種理想的解決方法。

由於電子商務等民用系統的應用需求，認證加密演算法也將有較大發展。此外，在傳統密碼體制中，還將會產生類似於IDEA這樣的新成員，新成員的一個主要特徵就是在演算法上有創新和突破，而不僅僅是對傳統演算法進行修正或改進。密碼學是一個正在不斷發展的年輕學科，任何未被認識的加/解密機制都有可能在其中佔有一席之地。

目前，對信息系統或電子郵件的安全問題，還沒有一個非常有效的解決方案，其主要原因是由於互聯網固有的異構性，沒有一個單一的信任機構可以滿足互聯網全程異構性的所有需要，也沒有一個單一的協議能夠適用於互聯網全程異構性的所有情況。解決的辦法只有依靠軟體代理了，即採用軟體代理來自動管理用戶所持有的證書（即用戶所屬的信任結構）以及用戶所有的行為。每當用戶要發送一則消息或一封電子郵件時，代理就會自動與對方的代理協商，找出一個共同信任的機構或一個通用協議來進行通信。在互聯網環境中，下一代的安全信息系統會自動為用戶發送加密郵件，同樣當用戶要向某人發送電子郵件時，用戶的本地代理首先將與對方的代理交互，協商一個適合雙方的認證機構。當然，電子郵件也需要不同的技術支持，因為電子郵件不是端到端的通信，而是通過多個中間機構把電子郵件分程傳遞到各自的通信機器上，最後到達目的地。

㈩ srtp是什麼意思

安全實時傳輸協議(Secure Real-time Transport Protocol)。

其是在實時傳輸協議(Real-time Transport Protocol)基礎上所定義的一個協議，旨在為單播和多播應用程序中的實時傳輸協議的數據提供加密、消息認證、完整性保證和重放保護。

由於實時傳輸協議和實時傳輸控制協議（Real-time Transport Control Protocol或RTCP）有著緊密的聯系，安全實時傳輸協議同樣也有一個伴生協議，它被稱為安全實時傳輸控制協議（Secure RTCP或SRTCP）；

安全實時傳輸控制協議為實時傳輸控制協議提供類似的與安全有關的特性，就像安全實時傳輸協議為實時傳輸協議提供的那些一樣。

對於 RTP 和 RTCP 應用程序來說, SRTP 和 SRTCP 是可選項, 而且即使使用了 SRTP 和 SRTCP 協議, 它們提供的各種功能(例如加密和認證) 也都是可以獨立選擇使用或者不使用的。

唯一的例外就是當使用 SRTCP 的時候消息認證(message authentication)是必選的。

數據流加密

為了提供對數據流的保密，需要對數據流進行加密和解密。關於這一點，安全實時傳輸協議（結合安全實時傳輸控制協議）只為一種加密演算法，即AES制定了使用標准。這種加密演算法有兩種加密模式，它們能將原始的AES塊密文轉換成流密文：

分段整型計數器模式——一種典型的計數器模式，它允許對任意塊的隨機訪問——這一點對於實時傳輸協議的數據流在可能丟包的不可靠網路上進行傳輸是非常必要的。一般情況下，幾乎所有的函數都能被作為計數器使用，只要它在一次循環中重復的次數不要太多就可以。

但是，用於實時傳輸協議數據加密的僅僅是一個普通的整型遞增計數器。運行在這一模式下的AES是其默認的加密演算法，它使用的是默認128位長度的加密密鑰和默認112位長度的會話鹽密鑰。

f8模式——輸出反饋模式的一個變種，它增加了定位功能並改變了初始化功能。其加密密鑰和鹽密鑰的默認值和計數器模式下的AES是一樣的。運行在這種模式下的AES被用於UMTS3G移動網路。

除了AES加密演算法，安全實時傳輸協議還允許徹底禁用加密，此時使用的是所謂的「零加密演算法」。它可以被認為是安全實時傳輸協議支持的第二種加密演算法，或者說是它所支持的第三種加密模式。

事實上，零加密演算法並不進行任何加密，也就是說，加密演算法把密鑰流想像成只包含「0」的流，並原封不動地將輸入流復制到輸出流。這種模式是所有與安全實時傳輸協議兼容的系統都必須實現的，因為它可以被用在不需要安全實時傳輸協議提供保密性保證而只要求它提供其它特性（如認證和消息完整性）的場合。

盡管從技術上來說安全實時傳輸協議能輕松地納入新的加密演算法，但安全實時傳輸協議標准指出除上述加密演算法以外的新的加密演算法不一定能被簡單地添加到一些安全實時傳輸協議的具體實現中去。

添加一種新的加密演算法並確保它與安全實時傳輸協議標准相兼容的唯一有效方式是發布一個明確定義該演算法的新的伴生的標准跟蹤RFC。

認證、完整性和重放保護

以上列舉的加密演算法本身並不能保護消息的完整性，攻擊者仍然可以偽造數據——至少可以重放過去傳輸過的數據。因此，安全實時傳輸協議標准同時還提供了保護數據完整性以及防止重放的方法。

為了進行消息認證並保護消息的完整性，安全實時傳輸協議使用了HMAC-SHA1演算法（在RFC 2104中定義）。這種演算法使用的是默認160位長度的HMAC-SHA1認證密鑰。

但是它不能抵禦重放攻擊；重放保護方法建議接收方維護好先前接收到的消息的索引，將它們與每個新接收到的消息進行比對，並只接收那些過去沒有被播放過的新消息。這種方法十分依賴於完整性保護的使用（以杜絕針對消息索引的欺騙技術）。