① 數據加密和數據簽名的原理作用
加密可以幫助保護數據不被查看和修改，並且可以幫助在本不安全的信道上提供安全的通信方式。例如，可以使用加密演算法對數據進行加密，在加密狀態下傳輸數據，然後由預定的接收方對數據進行解密。如果第三方截獲了加密的數據，解密數據是很困難的。
在一個使用加密的典型場合中，雙方（小紅和小明）在不安全的信道上通信。小紅和小明想要確保任何可能正在偵聽的人無法理解他們之間的通信。而且，由於小紅和小明相距遙遠，因此小紅必須確保她從小明處收到的信息沒有在傳輸期間被任何人修改。此外，她必須確定信息確實是發自小明而不是有人模仿小明發出的。
加密用於達到以下目的：
保密性：幫助保護用戶的標識或數據不被讀取。
數據完整性：幫助保護數據不更改。
身份驗證：確保數據發自特定的一方。
為了達到這些目的，您可以使用演算法和慣例的組合（稱作加密基元）來創建加密方案。下表列出了加密基元及它們的用法。
加密基元 使用
私鑰加密（對稱加密） 對數據執行轉換，使第三方無法讀取該數據。此類型的加密使用單個共享的機密密鑰來加密和解密數據。
公鑰加密（不對稱加密） 對數據執行轉換，使第三方無法讀取該數據。此類加密使用公鑰/私鑰對來加密和解密數據。
加密簽名 通過創建對特定方唯一的數字簽名來幫助驗證數據是否發自特定方。此過程還使用哈希函數。
加密哈希 將數據從任意長度映射為定長位元組序列。哈希在統計上是唯一的；不同的雙位元組序列不會哈希為同一個值。
私鑰加密
私鑰加密演算法使用單個私鑰來加密和解密數據。由於具有密鑰的任意一方都可以使用該密鑰解密數據，因此必須保護密鑰不被未經授權的代理得到。私鑰加密又稱為對稱加密，因為同一密鑰既用於加密又用於解密。私鑰加密演算法非常快（與公鑰演算法相比），特別適用於對較大的數據流執行加密轉換。
通常，私鑰演算法（稱為塊密碼）用於一次加密一個數據塊。塊密碼（如 RC2、DES、TrippleDES 和 Rijndael）通過加密將 n 位元組的輸入塊轉換為加密位元組的輸出塊。如果要加密或解密位元組序列，必須逐塊進行。由於 n 很小（對於 RC2、DES 和 TripleDES，n = 8 位元組；n = 16 [默認值]；n = 24；對於 Rijndael，n = 32），因此必須對大於 n 的值一次加密一個塊。
基類庫中提供的塊密碼類使用稱作密碼塊鏈 (CBC) 的鏈模式，它使用一個密鑰和一個初始化向量 (IV) 對數據執行加密轉換。對於給定的私鑰 k，一個不使用初始化向量的簡單塊密碼將把相同的明文輸入塊加密為同樣的密文輸出塊。如果在明文流中有重復的塊，那麼在密文流中將存在重復的塊。如果未經授權的用戶知道有關明文塊的結構的任何信息，就可以使用這些信息解密已知的密文塊並有可能發現您的密鑰。若要克服這個問題，可將上一個塊中的信息混合到加密下一個塊的過程中。這樣，兩個相同的明文塊的輸出就會不同。由於該技術使用上一個塊加密下一個塊，因此使用了一個 IV 來加密數據的第一個塊。使用該系統，未經授權的用戶有可能知道的公共消息標頭將無法用於對密鑰進行反向工程。
可以危及用此類型密碼加密的數據的一個方法是，對每個可能的密鑰執行窮舉搜索。根據用於執行加密的密鑰大小，即使使用最快的計算機執行這種搜索，也極其耗時，因此難以實施。使用較大的密鑰大小將使解密更加困難。雖然從理論上說加密不會使對手無法檢索加密的數據，但這確實極大增加了這樣做的成本。如果執行徹底搜索來檢索只在幾天內有意義的數據需要花費三個月的時間，那麼窮舉搜索的方法是不實用的。
私鑰加密的缺點是它假定雙方已就密鑰和 IV 達成協議，並且互相傳達了密鑰和 IV 的值。並且，密鑰必須對未經授權的用戶保密。由於存在這些問題，私鑰加密通常與公鑰加密一起使用，來秘密地傳達密鑰和 IV 的值。
假設小紅和小明是要在不安全的信道上進行通信的雙方，他們可能按以下方式使用私鑰加密。小紅和小明都同意使用一種具有特定密鑰和 IV 的特定演算法（如 Rijndael）。小紅撰寫一條消息並創建要在其上發送該消息的網路流。接下來，她使用該密鑰和 IV 加密該文本，並通過 Internet 發送該文本。她沒有將密鑰和 IV 發送給小明。小明收到該加密文本並使用預先商定的密鑰和 IV 對它進行解密。如果傳輸的內容被人截獲，截獲者將無法恢復原始消息，因為截獲者並不知道密鑰或 IV。在這個方案中，密鑰必須保密，但 IV 不需要保密。在一個實際方案中，將由小紅或小明生成私鑰並使用公鑰（不對稱）加密將私鑰（對稱）傳遞給對方。有關更多信息，請參見本主題後面的有關公鑰加密的部分。
.NET Framework 提供以下實現私鑰加密演算法的類：
DESCryptoServiceProvider
RC2CryptoServiceProvider
RijndaelManaged
公鑰加密
公鑰加密使用一個必須對未經授權的用戶保密的私鑰和一個可以對任何人公開的公鑰。公鑰和私鑰都在數學上相關聯；用公鑰加密的數據只能用私鑰解密，而用私鑰簽名的數據只能用公鑰驗證。公鑰可以提供給任何人；公鑰用於對要發送到私鑰持有者的數據進行加密。兩個密鑰對於通信會話都是唯一的。公鑰加密演算法也稱為不對稱演算法，原因是需要用一個密鑰加密數據而需要用另一個密鑰來解密數據。
公鑰加密演算法使用固定的緩沖區大小，而私鑰加密演算法使用長度可變的緩沖區。公鑰演算法無法像私鑰演算法那樣將數據鏈接起來成為流，原因是它只可以加密少量數據。因此，不對稱操作不使用與對稱操作相同的流模型。
雙方（小紅和小明）可以按照下列方式使用公鑰加密。首先，小紅生成一個公鑰/私鑰對。如果小明想要給小紅發送一條加密的消息，他將向她索要她的公鑰。小紅通過不安全的網路將她的公鑰發送給小明，小明接著使用該密鑰加密消息。（如果小明在不安全的信道如公共網路上收到小紅的密鑰，則小明必須同小紅驗證他具有她的公鑰的正確副本。）小明將加密的消息發送給小紅，而小紅使用她的私鑰解密該消息。
但是，在傳輸小紅的公鑰期間，未經授權的代理可能截獲該密鑰。而且，同一代理可能截獲來自小明的加密消息。但是，該代理無法用公鑰解密該消息。該消息只能用小紅的私鑰解密，而該私鑰沒有被傳輸。小紅不使用她的私鑰加密給小明的答復消息，原因是任何具有公鑰的人都可以解密該消息。如果小紅想要將消息發送回小明，她將向小明索要他的公鑰並使用該公鑰加密她的消息。然後，小明使用與他相關聯的私鑰來解密該消息。
在一個實際方案中，小紅和小明使用公鑰（不對稱）加密來傳輸私（對稱）鑰，而對他們的會話的其餘部分使用私鑰加密。
公鑰加密具有更大的密鑰空間（或密鑰的可能值范圍），因此不大容易受到對每個可能密鑰都進行嘗試的窮舉攻擊。由於不必保護公鑰，因此它易於分發。公鑰演算法可用於創建數字簽名以驗證數據發送方的身份。但是，公鑰演算法非常慢（與私鑰演算法相比），不適合用來加密大量數據。公鑰演算法僅對傳輸很少量的數據有用。公鑰加密通常用於加密一個私鑰演算法將要使用的密鑰和 IV。傳輸密鑰和 IV 後，會話的其餘部分將使用私鑰加密。
.NET Framework 提供以下實現公鑰加密演算法的類：
DSACryptoServiceProvider
RSACryptoServiceProvider
數字簽名
公鑰演算法還可用於構成數字簽名。數字簽名驗證發送方的身份（如果您信任發送方的公鑰）並幫助保護數據的完整性。使用由小紅生成的公鑰，小紅的數據的接收者可以通過將數字簽名與小紅的數據和小紅的公鑰進行比較來驗證是否是小紅發送了該數據。
為了使用公鑰加密對消息進行數字簽名，小紅首先將哈希演算法應用於該消息以創建消息摘要。該消息摘要是數據的緊湊且唯一的表示形式。然後，小紅用她的私鑰加密該消息摘要以創建她的個人簽名。在收到消息和簽名時，小明使用小紅的公鑰解密簽名以恢復消息摘要，並使用與小紅所使用的相同的哈希演算法來散列消息。如果小明計算的消息摘要與從小紅那裡收到的消息摘要完全一致，小明就可以確定該消息來自私鑰的持有人，並且數據未被修改過。如果小明相信小紅是私鑰的持有人，則他知道該消息來自小紅。
請注意，由於發送方的公鑰為大家所周知，並且它通常包含在數字簽名格式中，因此任何人都可以驗證簽名。此方法不保守消息的機密；若要使消息保密，還必須對消息進行加密。
.NET Framework 提供以下實現數字簽名演算法的類：
DSACryptoServiceProvider
RSACryptoServiceProvider
哈希值
哈希演算法將任意長度的二進制值映射為固定長度的較小二進制值，這個小的二進制值稱為哈希值。哈希值是一段數據唯一且極其緊湊的數值表示形式。如果散列一段明文而且哪怕只更改該段落的一個字母，隨後的哈希計算都將產生不同的值。要找到散列為同一個值的兩個不同的輸入，在計算上是不可能的。
消息身份驗證代碼 (MAC) 哈希函數通常與數字簽名一起用於對數據進行簽名，而消息檢測代碼 (MDC) 哈希函數則用於數據完整性。
雙方（小紅和小明）可按下面的方式使用哈希函數來確保數據的完整性。如果小紅對小明編寫一條消息並創建該消息的哈希，則小明可以在稍後散列該消息並將他的哈希與原始哈希進行比較。如果兩個哈希值相同，則該消息沒有被更改；如果值不相同，則該消息在小紅編寫它之後已被更改。為了使此系統發揮作用，小紅必須對除小明外的所有人保密原始的哈希值。
.NET Framework 提供以下實現數字簽名演算法的類：
HMACSHA1
MACTripleDES
MD5CryptoServiceProvider
SHA1Managed
SHA256Managed
SHA384Managed
SHA512Managed
隨機數生成
隨機數生成是許多加密操作不可分割的組成部分。例如，加密密鑰需要盡可能地隨機，以便使生成的密鑰很難再現。加密隨機數生成器必須生成無法以計算方法推算出（低於 p < .05 的概率）的輸出；即，任何推算下一個輸出位的方法不得比隨機猜測具有更高的成功概率。.NET Framework 中的類使用隨機數生成器生成加密密鑰。
RNGCryptoServiceProvider 類是隨機數生成器演算法的實現。
② 手機相冊加密1234為什麼打不開提示也是1234
因為手機卡住了，你可以試試重新啟動。
③ 加密、簽名、證書的作用及運用場景
本文主要是簡單介紹了常見的加密類型、各自的運用場景、為什麼需要數字簽名和數字證書、HTTPS涉及到的加密流程等。這里主要從使用者的角度出發，對演算法本身不做過多介紹。
對稱/非對稱加密均屬於 可逆加密，可以通過密鑰將密文還原為明文 。
有時候，我們希望明文一旦加密後，任何人（包括自己）都無法通過密文逆推回明文，不可逆加密就是為了滿足這種需求。
不可逆加密主要通過 hash演算法實現：即對目標數據生成一段特定長度hash值 ；無論你的數據是1KB、1MB、1GB，都是生成特定長度的一個Hash值（比如128bit）。這里大家應該能感受到一點 不可逆 的味道，加密後128bit的hash值顯然無法還原出1個G甚至更大的不規則數據的， hash可以看做是原來內容的一個摘要 。
常見演算法：
小明給小紅寫信：
經過九轉十八彎後，信的內容有可能：1. 被窺視 2. 被篡改（冒充小明發送假消息） ：
小紅先 生成對稱加密的密鑰key1 ，然後通過一個安全的渠道交予小明。
傳輸數據時，小明 使用key1加密 ，而小紅收到後再 使用key1解密 。
這時候 中間者既看不到原來的內容，也沒辦法篡改 （因為沒有密鑰）：
【對稱加密】實現簡單，性能優秀 ，演算法本身安全級別高。然而對 密鑰的管理 卻是個很頭疼的問題：一旦密鑰交到對方手裡，對方對密鑰的保管能力 我方是沒辦法控制 的，一旦對方泄露的話，加密就形同虛設了。
相對而言，【非對稱加密】的公鑰就沒有這個憂慮，因為 公鑰 的設計就是為了 可以公開的 ，盡管對方泄露，我方也不會有任何損失。
小紅生成一對公私鑰，自己持有私鑰（pri_key1），將公鑰（pub_key1）交予小明。
傳輸數據時，小明使用 公鑰加密 ，小紅使用 私鑰解密 。
因為 中間者沒有私鑰，公鑰加密的內容是無法獲取的 。此時達到了 防窺視 的效果：
然而因為 公鑰是可以公開的 ，如果 中間者知曉公鑰 的話，盡管沒有辦法看到原來的內容，卻 可以冒充小明發送假消息 ：
這時小紅在想，如果小明發送消息時，能帶上 只有他自己才能生成 的數據（字元串），我就能 驗證是不是小明發的真實消息 了。
通常這個 能證實身份的數據（字元串） 被稱之為 數字簽名（Signature）
小明再生成一對公私鑰 ，自己持有私鑰（pri_key2），將公鑰交予小紅（pub_key2）。
當小明傳輸數據時（可能很大），除了公鑰加密明文之外，還要帶上簽名：(1) 對明文做一個hash摘要 (2)對摘要進行私鑰加密，加密結果即簽名（傳輸內容=內容密文+簽名）
小紅收到後：(1) 解密簽名獲取hash (2)解密內容密文，對解密後的明文進行hash；如果兩個hash一致，說明驗簽通過。
盡管中間者修改了傳輸內容，但因為簽名無法冒認（沒有私鑰），小紅驗簽失敗，自然不會認可這份數據：
通常 非對稱加密要做到防窺視和防篡改，需要有兩對公私鑰 ：對方的公鑰用於內容加密，自己的私鑰用於簽名（讓對方驗證身份）。
因為HTTP協議明文通信的安全問題，引入了HTTPS：通過建立一個安全通道（連接），來保證數據傳輸的安全。
伺服器是 沒辦法直接將密鑰傳輸到瀏覽器的 ，因為在 安全連接建立之前，所有通信內容都是明文的 ，中間者可窺視到密鑰信息。
或許這時你想到了非對稱加密，因為公鑰是不怕公開的：
然而在第2步， 中間者可以截取伺服器公鑰，並替換成了自己的公鑰 ，此時加密就沒意義了：
為了 防止公鑰被假冒，數字證書（digital certificate ）便誕生了 。
當伺服器需要告訴瀏覽器公鑰時，並不是簡單地返回公鑰，而是響應 包含公鑰信息在內的數字證書 。
證書主要包含以下內容：
瀏覽器通過 【頒發機構的公鑰】進行解密驗簽 ，驗簽通過即說明證書的真實性，可以放心取 證書擁有者的公鑰 了。（ 常用CA機構的公鑰都已經植入到瀏覽器裡面 ）
數字證書只做一件事： 保證 伺服器響應的 公鑰是真實的 。
以上保證了 [瀏覽器⇒伺服器] 是加密的，然而 [伺服器⇒瀏覽器] 卻沒有（上圖第4步）；另外一個是 性能問題 ，如果所有數據都使用非對稱加密的話，會消耗較多的伺服器資源，通信速度也會受到較大影響。
HTTPS巧妙地結合了非對稱加密和對稱加密，在保證雙方通信安全的前提下，盡量提升性能。
HTTPS（SSL/TLS）期望 建立安全連接後，通信均使用【對稱加密】 。
建立安全連接的任務就是讓 瀏覽器-伺服器協商出本次連接使用的【對稱加密的演算法和密鑰】 ；協商過程中會使用到【非對稱加密】和數字證書。
特別注意的是：協商的密鑰必須是不容易猜到（足夠隨機的）：
其中比較核心的是隨機數r3（pre-master secret），因為之前的r1、r2都是明文傳輸的， 只有r3是加密傳輸 的。至於為什麼需要三個隨機數，可以參考：
以上是一個比較簡單的HTTPS流程，詳細的可以參考文末的引用。
參考資料：
[1] 數字證書應用綜合揭秘
[2] SSL/TLS協議運行機制的概述
[3] 圖解SSL/TLS協議
[4] 《圖解HTTP》
④ 關於公私鑰、各種證書、https基本概念掃盲
最近實習需要寫一些生成證書的腳本，藉此機會順便搞清楚了許多關於證書這塊的疑惑。說到這一塊東西，名詞多到爆炸，對稱加密、非對稱加密、密鑰、密鑰庫、公鑰、私鑰、CA、證書、數字簽名、ssh、https、ssl、keytool、openssl、PKCS、X.509以及令人眼花繚亂的文件後綴名，cer、crt、pem、keystore、jks、key、p12、pfx...
先聽我講個故事，這次我們不用Bob和Alice,聽完之後再去看這些概念，絕壁恍然大悟。
故事背景: 這是2018年，為了能夠安全的進行通信，假設每個人都有倆把鎖，一個叫A鎖，一個叫B鎖，這倆把鎖和一般的鎖有點區別，每把鎖上即帶有自己的鎖孔又帶有另一把鎖的鑰匙，因此A鎖和B鎖既是鎖又是鑰匙。 A鎖和B鎖唯一配對，A鎖鎖住之後，只有B鎖可以打開，同樣B鎖鎖住之後，只有A鎖可以打開 。其中一把鎖是公開的，而一把鎖則自己保管，不公開。假設默認A鎖是公開的，B鎖是私有的。
故事內容: 阿里巴巴子弟小學的小明想給隔壁班的小花寫封表白信，為了不被別人看到，他將信放入在信箱中，並用小花的A鎖將信箱鎖住，因為小花的B鎖(同是A鎖的鑰匙)只有小花自己有，所以除了小花以外的任何人拿到信件，都無法看到信件內容。同樣小花要給小明寫信，那麼也要用小明的A鎖對信件內容進行保護。
小明與小花通過就這樣聊了有一段時間，後來小花覺得差不多了，可以進入秀恩愛的階段了，跟小明說，以後寫信別tm加密了，又不是銀行卡密碼，被人看到又能怎麼樣呢？只要看了之後別瞎改就行了。於是小明在寫完信後，把信里每個字的拼音首字母拼湊了一個字元串，並取名為 消息摘要 ，然後僅僅將消息摘要放入信箱，用自己的B鎖鎖住這個信箱。雖然信件本身沒有放入安全的信箱，但小明作為一個情書高手，隨便一封信都是上萬字，如果其他人對信件內容做任何改變，那麼拼音首字母組成的字元串幾乎肯定會改變，因此小花拿到信件後，先用小明的A鎖(B鎖的鑰匙)打開信箱，拿到小明的摘要,然後小花再對信件內容做同樣的處理(即計算信件每個字的拼音首字母，實際上不會用這么簡單的演算法，而是會用不可逆的hash演算法)，計算出的字元串值如與小明的信息摘要一致，說明這封信就是小明寫給自己的，沒有被任何人篡改。
故事高潮: 事情並沒有那麼簡單，小花發現小明只是在信件里對自己熱情似火，平常見了面連聲招呼都不打，一副不認識的樣子。終於有一天小花忍不住了，當面質問小明，小明卻說，我什麼時候給你寫情書了，自作多情吧...於是小花把昨天剛收到的情書狠狠甩在了小明臉上:「上面落款不是你小明嗎？怎麼了,慫了？」小明一看上面還真是自己的名字，但是自己寫沒寫信自己還不知道嗎？小明把自己的作業本拿給小花，並叫自己的同桌做筆跡鑒定，小花發現筆跡的確不大像，看來是有人惡作劇，冒充小明給自己寫情書，哎，好尷尬啊。。。
故事講完了，文章開頭涉及的所有概念都與信息的安全傳輸有關，可以說，一切都是為了安全。關於通信安全，我們通常有三個基本的需求
我們以上面的故事為例說一下這三點安全需求，一開始小明與小花通過A鎖( 對應公鑰 )加密,B鎖( 對應私鑰 )解密的通信方式即符合第一點，信件內容本身被加密，而因為公私鑰唯一配對，只有配對的密鑰才可以解密，因此很難被第三人破解。
之後，為了秀恩愛，他們採用了B鎖( 私鑰 )加密，A鎖( 公鑰 )解密的通信方式，其中用私鑰對消息摘要加密後的字元串稱為 數字簽名 ,這樣雖然信件可以被人直接看到，但如果被人篡改掉後可以輕易發現數據被篡改。本來以為滿足第一條和第二條就可以安全的通信了，但最後才發現小明根本不是小明！為什麼會出現這樣的問題？因為「小明」說他是小明，小花就以為他是小明，他沒有提供任何證明自己真的是小明的認證。因此要想安全通信，我們還需要一個權威第三方的機構來做身份認證,這個機構就是CA機構，通過認證後，CA機構會頒發權威的證書，而有了證書就可以證明身份，就不會出現身份被假冒的情況。而認證的過程則需要向CA機構提供自己的身份信息以及私鑰。
對稱加密就是通信雙方或多方採用的密鑰是一樣的。加解密速度快，但不夠安全。因為一旦密鑰泄露，誰都可以對數據進行解密。非對稱加密就是當然就是通信雙方使用的密鑰不同。而公鑰和私鑰就是非對稱加密的一種方式。比較常用的對稱加密演算法如
AES、DES，非對稱加密比較常見的則有sha256,RSA。
非對稱加密演算法有倆個密鑰，一個公鑰，一個私鑰。公鑰和私鑰必須配對出現，一對公鑰和一個私鑰統稱為一個 密鑰 ，而 密鑰庫 中可以存放多個密鑰，即多對公私鑰。
如果你用github的話，應該注意到github鏈接有倆種方式。一種是https,一種是ssh,通過https經常需要輸密碼，而通過ssh則不需要。回憶你設置ssh的步驟，本地生成了一個密鑰對，並將公鑰上傳到了github。每次傳輸用自動本地私鑰加密，伺服器用你上傳的公鑰解密，就不需要手動輸入密碼了。
keytool和openssl是倆個證書管理工具.keytool是java JDK自帶的證書管理工具，使用keytool可以生成密鑰，創建證書。只要裝了jdk,並正確設置了環境變數，就可以之間通過命令行執行keytool命令來管理證書。
openssl則是一個開源的安全套接字層密碼庫，功能比keytool更加豐富。
PKCS全稱Public-Key Cryptography Standards 即公鑰標准，PKCS已經發布了15個標准。
PKCS#12 包含了公鑰和私鑰的二進制格式的證書形式，以pfx作為證書文件後綴
X.509 則是一個通用的證書標准，規定了證書應該包含哪些內容，X.509通常有倆種編碼方式，一種是二進制編碼，另一種是base64編碼
X.509#DER 二進制格式證書，常用後綴.cer .crt
X.509#PEM 文本格式證書，常用後綴.pem
因為http是明文傳輸，非常不安全，因此又提出了ssl(Secure Sockets Layer即安全套接字)層協議，即在原來的基礎上又加了一層協議用於保障安全傳輸,可以認為https=ssl+http。很多人剛開始接觸https，用瀏覽器F12打開控制台後。可能發現數據仍然沒有加密。要注意https是 傳輸層加密 ，瀏覽器F12控制台你看到的還是應用層的數據。
因為本文主要是概念掃盲，幫助理解，因此關於這部分具體細節不作介紹。
.keystore和.jks和.truststore都是java用來存放密鑰的文件
.key nginx中私鑰文件
而不同的證書文件後綴都是為了區分不同種類的證書的，主要有倆個分類維度
⑤ 四、公鑰和私鑰，加密和數字簽名
本文涉及到支付寶SDK的內容，均摘自支付寶開放平台。
因為支付寶SDK使用RSA來加密和生成數字簽名，所以本文中涉及到的概念也都是針對於RSA的。
一對兒密鑰生成後，會有公鑰和私鑰之分，我們需要把私鑰保存下來，而把公鑰發布出去。一對兒公鑰和私鑰，不能由其中一個導出另一個。
比如使用支付寶SDK的時候，我們商戶端會生成一對兒密鑰A和B，A是私鑰，B是公鑰，支付寶也會生成一對兒密鑰C和D，C是私鑰，D是公鑰。我們商戶端需要把商戶端私鑰A保存下來，而把商戶端公鑰B發布出去給支付寶，支付寶需要把支付寶私鑰C保存下來，而把支付寶公鑰D發布出去給我們商戶端。
加密是指我們使用一對兒密鑰中的一個來對數據加密，而使用另一個來對數據解密的技術，需要注意的是公鑰和私鑰都可以用來加密，也都可以用來解密 ，並不是規定死了只能用公鑰加密私鑰解密，但是加解密必須是一對兒密鑰之間的互相加解密，否則不能成功。
加密的目的是為了保證數據的不可讀性，防止數據在傳輸過程中被截獲。
知道了加密這個概念，我們先看一下支付寶的加密過程，再引出數字簽名這個概念。接著第1小節的例子，當我們商戶端和支付寶互相發布了公鑰之後，我們商戶端手裡就有 商戶端私鑰 和 支付寶公鑰 兩個密鑰，支付寶手裡也有 商戶端公鑰 和 支付寶私鑰 兩個密鑰。現在假設我們商戶端要給支付寶傳輸訂單信息，那麼為了保證傳輸訂單信息時數據的安全性，結合我們商戶端手裡所擁有的密鑰，可以有兩套加密方案
貌似這兩套加密方案都能達到對訂單信息加密的效果，而且如果採用方案二，我們商戶端甚至只需要存儲支付寶公鑰這一個密鑰，都不用去申請一對兒商戶端的公私鑰來維護，支付寶也不用保存我們一堆商戶那麼多的商戶端公鑰了，這不是更簡單嗎，那為什麼支付寶開放平台讓我們採用的是方案一而不是方案二呢？下面來回答一下。
支付寶開放平台說明：當我們採用RSA（1024位密鑰）來加密的時候，支付寶分配給所有商戶的支付寶公鑰都是一樣的，即支付寶針對那麼多的商戶只負責維護一對兒支付寶公私鑰，這就意味著支付寶公鑰隨便什麼人拿到後都是一樣的；而當我們採用RSA2（2048位密鑰）來加密的時候，支付寶會分配給每個商戶單獨的一個支付寶公鑰，即支付寶為每一個的商戶單獨的維護一對獨立的支付寶公私鑰，當然一個商戶下的多個App的支付寶公鑰是一樣的。RSA是早就支持的，RSA2是最近才支持的。
知道了上面這段話，現在假設我們採用的是方案二，並且採用RSA加密（很多老業務並沒有使用RSA2加密），業務邏輯將會是下面這樣。
這就出問題了， RSA加密下，支付寶公鑰是公開發布的，而且所有的商戶用的都是同一個支付寶公鑰（上面聲明了RSA2加密下，支付寶才針對每個商戶維護了一對兒公私鑰），攻擊者很容易就能獲取到，而 notify_url 也很容易被截獲，那攻擊者拿到這兩個東西就可以做和商戶一樣的操作來發起支付請求，這樣就會一直給小明充錢了。
所以 支付寶就需要確認支付請求確實是商戶發給他們的，而不是攻擊者發給他們的。 這就用到了 數字簽名 ，我們會通過方案一的實現流程來引出數字簽名的具體概念。如果我們採用的是方案一，我們商戶端保存的就是商戶端私鑰和支付寶公鑰，而支付寶保存的就是需要存著商戶端公鑰和支付寶私鑰的，業務邏輯將會是下面這樣。
這樣就可以保證交易的安全性了，我們也可以看出使用支付寶SDK保證交易的安全性注重的其實不是訂單信息是否加密，而是如何確保商戶端和支付寶能夠互相確認身份，訂單信息是明文的，但是後面拼接了數字簽名。
數字簽名其實就是明文數據加密之後得到的一個密文，只不過它是用私鑰加密生成的而已，我們一般會把數字簽名拼接在明文數據後面一起傳遞給接收方，接收方收到後用公鑰解密數字簽名，從而驗證發送方的身份、以及明文數據是否被篡改。數字簽名的生成過程其實就是一個加密過程，數字簽名的驗簽過程就是一個解密過程。
數字簽名的目的有兩個：一、發送方和接收方互相驗證身份；二、驗證數據是否被篡改。
從上面第一部分我們知道為了確保商戶和支付寶交易的安全性，約定採用的是給訂單信息加數字簽名傳輸的方式。支付寶也為我們提供了 一鍵生成RSA密鑰的工具 ，可以幫助我們很快的生成一對商戶端公私鑰。以下會對支付寶SDK的支付流程做個大概的解釋，並點出實際開發中我們使用支付寶SDK時應該注意的地方。
由我們商戶端自己生成的RSA私鑰（必須與商戶端公鑰是一對），生成後要保存在服務端，絕對不能保存在客戶端，也絕對不能從服務端傳輸給客戶端。
用來對訂單信息加簽，加簽過程一定要在服務端完成，絕對不能在客戶端做加，客戶端只負責用加簽後的訂單信息調起支付寶來支付。
由我們商戶端自己生成的RSA公鑰（必須與商戶端私鑰是一對），生成後需要填寫在支付寶開放平台。
用來給支付寶服務端驗簽經過我們加簽後的訂單信息，以確保訂單信息確實是我們商戶端發給支付寶的，並且確保訂單信息在傳輸過程中未被篡改。
這個和我們就沒關系了，支付寶私鑰是他們自己生成的，也是他們自己保存的。
用來對支付結果進行加簽。
支付寶公鑰和支付寶私鑰是一對，也是支付寶生成的，當我們把商戶端公鑰填寫在支付寶開放平台後，平台就會給我們生成一個支付寶公鑰，我們可以復制下來保存在服務端，同樣不要保存在客戶端，並且不要傳輸給客戶端。
用來讓服務端對支付寶服務端返給我們的同步或非同步支付結果進行驗簽，以確保支付結果確實是由支付寶服務端返給我們服務端的，而且沒有被篡改，對支付結果的驗簽工作也一定要在服務端完成。
上面已經說過了： 訂單信息的加簽和支付結果的驗簽是一定要在服務端做的，絕對不能在客戶端做。
下面是在客戶端對訂單信息加簽的過程，僅僅是為了模擬服務端來表明訂單信息是如何通過加簽最終轉變為orderString的， 千萬不要覺得訂單信息的加簽過程也可以放在客戶端完成 。
假設我們服務端收到了來自支付寶服務端的支付結果，即： 支付結果+數字簽名 。
那麼我們服務端就會對支付結果進行驗簽，怎麼個驗法呢？
⑥ flow3d安裝一直在keydrivers
在安裝Flow3D軟體時，如果安裝程序一直停留在「keydrivers」階段，可能是由於以下原因：
1. 未正確安裝或未更新驅動程序。Flow3D軟體需要與計算機的圖形卡進行通信，因此需要安裝正確的驅動程序。如果您的計算機沒有正確安裝或更新驅動程序，那麼安裝程序可能會在keydrivers階段卡住。
2. 計算機硬體不符合要求。Flow3D軟體需要計算機硬體來提供足夠的計算能力，以便進行流體動力學模擬計算。如果您的計算蠢老機硬體不符合Flow3D軟體的最低硬體要求，那麼安裝程序可能會在keydrivers階段卡住。
3. 安裝程序本身存在問題。有時，安裝程序本身可能存在錯誤或損壞，這可能會導致安裝程序在keydrivers階段卡住。
為了解決這個問宴檔芹題，您可以嘗試以下步驟：
1. 確保您的計算機已正確安裝或更新了最新的驅動程序。您可以通過訪問圖形卡製造商的網站來下載和安裝最新的驅動程序。
2. 確保您的計算機符合Flow3D軟體的最低硬體要求。您可以在Flow3D軟體的官方網站上查看最低硬體要求。
3. 嘗試重新下載和安裝Flow3D軟體。確保您下載的安裝程序沒有損壞，並且您已經按照安裝程序提供的說明正確安裝了軟體。晌畢
同時，建議您在安裝Flow3D軟體之前備份您的計算機數據，以防止數據丟失。
⑦ 4. 小明為了方便記憶,把自己的生日設成電腦密碼,安全嗎
不是很安全。
將密碼設置成生日很容易被人破解。
密碼是一種用來混淆的技術，它希望將正常的信息轉變為無法識別的信息。當然，對一小部分人來說，這種無法識別的信息是可以再加工並恢復的。密碼在中文裡是"口令"的通稱。登錄網站、電子郵箱和銀行取款時輸入的"密碼"其實嚴格來講應該僅被稱作"口令"，因為它不是本來意義上的"加密代碼"，但是也可以稱為秘密的號碼。主要限定於個別人理解的符號系統。如密碼電報、密碼式打字機。
⑧ 小明q1迷你投影儀密碼是多少啊
初始密碼為1234.
根據什麼值得買網中的相關信息，小明q1迷你悄咐投影儀綜合來看是一款性價比非常啟滾純高的入門投影設備，很適合年輕人自由、有追求的生活所需，而此設備的初始密碼為1234。
小明Q1迷你投影儀的外觀造型非常有個性，相比較「毫無感情」、冷冰冰的方盒子一般的常規投影儀，此作做工比較精細，配合沒有稜角的圓潤機身和碩大的光源，又萌又可愛，隱約有一種「大眼萌」的備棗既視感。
⑨ 易語言加密解密問題,是bug嗎為什麼1234解密不出來,還有些也解不出來 .
應該不是漏洞，以下是我對你的源碼的改正：
.版本 2
.支持庫 dp1
.子程序 BASE64編碼, 文本型, , BASE64編碼處理(返回編碼後的文本)
.參數 待編碼數據, 位元組集, , 待編碼位元組集
.局部變數 余數
.局部正升變數 臨時, 位元組型, , "3"
.局部變數 變數
.局部變數 集合, 位元組集
.局部變數 長度, 整數型
.局部變數 字元, 位元組集
.局部變數 i
長度 ＝ 取位元組集長度 (待編碼數據)
.如果真 (長度 ＜ 1)
返回 (「」)
.如果真結束
余數 ＝ 長度 ％ 3
.如果真 (余數 ＞ 0)
待編碼數據 ＝ 待編碼數據 ＋ 取空白位元組集 (3 － 余數)
.如果真結束
長度 ＝ 取位元組集長度 (待編碼數據)
字元 ＝ 取空白位元組集 (長度 × 4 ÷ 3)
i ＝ 1
集合 ＝ 到位元組集 (「+/」)
.變數循環首 (1, 長度, 3, 變數)
臨時 [1] ＝ 待編碼數據 [變數]
臨時 [2] ＝ 待編碼數據 [變數 ＋ 1]
臨時 [3] ＝ 待編碼數裂叢據 [變數 ＋ 2]
字元 [i] ＝ 集合 [右移 (臨時 [1], 2) ＋ 1]
字元 [i ＋ 1] ＝ 集合 [左移 (位與 (臨時 [1], 3), 4) ＋ 右移 (臨時 [2], 4) ＋ 1]
字元 [i ＋ 2] ＝ 集合 [左移 (位與 (臨時 [2], 15), 2) ＋ 右移 (臨時 [3], 6) ＋ 1]
字元 [i ＋ 3] ＝ 集合 [位與 (臨時 [3], 63) ＋ 1]
i ＝ i ＋ 4
.變數循環尾 ()
.如果真 (余數 ＞ 0)
長度 ＝ 取位元組集長度 (字元)
.如果 (余數 ＝ 1)
字元 [長度 － 1] ＝ 取代碼 (「=」, )
字元 [長度] ＝ 取代碼 (「=」, )
.否則
字元 [長度] ＝ 取代碼 (「=」, )
.如果結束
.如果真結束
返回 (到文本 (字元))
.子程序 BASE64解碼, 位元組集, , BASE64解碼處理(返回解碼後的位元組集數據)
.參數 編碼文本, 文本型, 參考, 待解碼的文本
.局部變數 文本長度
.局部變數 整倍數
.局部變數 三位元組組, 位元組型, , "3"
.局部變數 四位元組組, 位元組型, , "4"
.局部變數 編碼值
.局部變數 X
.局部變數 n
.局部變數 二進制數據, 位元組集
編碼文本 ＝ 刪全部空 (編碼文本)
編碼文本 ＝ 子文本替換 (編碼文本, #換行符, , , , 真)
文本長度 ＝ 取文本長度 (編碼文本)
整倍數 ＝ 文本長度 ＼ 4
.如果真 (文本長度 ％ 4 ≠ 0)
整倍數 ＝ 整倍數 ＋ 1
.如果真結束
.計次循環首 (整倍數, X)
.計次循環首 (4, n)
四位元組組 [n] ＝ 取代碼 (編碼文本, (X － 1) × 4 ＋ n)
編碼值 ＝ 尋找文本 (「+/」, 字元 (四位元組組 [n]), , 假)
.如果真 (編碼值 ＝ -1)
跳出循環 ()
.如果真結束
四位元組組 [n] ＝ 編碼值 － 1
.計次循環尾 ()
三位元組組 [1] ＝ 位或 (四位元組組 [1] × 4, 四位元組組 [2] ÷ 16)
三位元組組 [2] ＝ 位或 (四位元組肆清櫻組 [2] × 16, 四位元組組 [3] ÷ 4)
三位元組組 [3] ＝ 位或 (四位元組組 [3] × 64, 四位元組組 [4])
二進制數據 ＝ 二進制數據 ＋ 到位元組集 (三位元組組)
處理事件 ()
.計次循環尾 ()
.如果真 (n ＜ 5) ' 最後一組4字元是提前退出的,截取位元組集
n ＝ 5 － n
二進制數據 ＝ 取位元組集左邊 (二進制數據, 取位元組集長度 (二進制數據) － n)
.如果真結束
返回 (二進制數據)
.子程序 _按鈕1_被單擊
編輯框2.內容 ＝ BASE64編碼 (加密數據 (到位元組集 (編輯框1.內容), 「123」, 1))
.子程序 _按鈕2_被單擊
編輯框3.內容 ＝ 到文本 (解密數據 (BASE64解碼 (編輯框2.內容), 「123」, 1))
⑩ 圖文徹底搞懂非對稱加密（公鑰密鑰）
前文詳細講解了對稱加密及演算法原理。那麼是不是對稱加密就萬無一失了呢？對稱加密有一個天然的缺點，就是加密方和解密方都要持有同樣的密鑰。你可以能會提出疑問：既然要加、解密，當然雙方都要持有密鑰，這有什麼問題呢？別急，我們繼續往下看。
我們先看一個例子，小明和小紅要進行通信，但是不想被其他人知道通信的內容，所以雙方決定採用對稱加密的方式。他們做了下面的事情：
1、雙方商定了加密和解密的演算法
2、雙方確定密鑰
3、通信過程中採用這個密鑰進行加密和解密
這是不是一個看似完美的方案？但其中有一個步驟存在漏洞！
問題出在步驟2：雙方確定密鑰！
你肯定會問，雙方不確定密鑰，後面的加、解密怎麼做？
問題在於確定下來的密鑰如何讓雙方都知道。密鑰在傳遞過程中也是可能被盜取的！這里引出了一個經典問題：密鑰配送問題。
小明和小紅在商定密鑰的過程中肯定會多次溝通密鑰是什麼。即使單方一次確定下來，也要發給對方。加密是為了保證信息傳輸的安全，但密鑰本身也是信息，密鑰的傳輸安全又該如何保證呢？難不成還要為密鑰的傳輸再做一次加密？這樣不就陷入了死循環？
你是不是在想，密鑰即使被盜取，不還有加密演算法保證信息安全嗎？如果你真的有這個想法，那麼趕緊復習一下上一篇文章講的杜絕隱蔽式安全性。任何演算法最終都會被破譯，所以不能依賴演算法的復雜度來保證安全。
小明和小紅現在左右為難，想加密就要給對方發密鑰，但發密鑰又不能保證密鑰的安全。他們應該怎麼辦呢？
有如下幾種解決密鑰配送問題的方案：
非對稱加密也稱為公鑰密碼。我更願意用非對稱加密這種叫法。因為可以體現出加密和解密使用不同的密鑰。
對稱加密中，我們只需要一個密鑰，通信雙方同時持有。而非對稱加密需要4個密鑰。通信雙方各自准備一對公鑰和私鑰。其中公鑰是公開的，由信息接受方提供給信息發送方。公鑰用來對信息加密。私鑰由信息接受方保留，用來解密。既然公鑰是公開的，就不存在保密問題。也就是說非對稱加密完全不存在密鑰配送問題！你看，是不是完美解決了密鑰配送問題？
回到剛才的例子，小明和下紅經過研究發現非對稱加密能解決他們通信的安全問題，於是做了下面的事情：
1、小明確定了自己的私鑰 mPrivateKey，公鑰 mPublicKey。自己保留私鑰，將公鑰mPublicKey發給了小紅
2、小紅確定了自己的私鑰 hPrivateKey，公鑰 hPublicKey。自己保留私鑰，將公鑰 hPublicKey 發給了小明
3、小明發送信息 「周六早10點soho T1樓下見」，並且用小紅的公鑰 hPublicKey 進行加密。
4、小紅收到信息後用自己的私鑰 hPrivateKey 進行解密。然後回復 「收到，不要遲到」 並用小明的公鑰mPublicKey加密。
5、小明收到信息後用自己的私鑰 mPrivateKey 進行解密。讀取信息後心裡暗想：還提醒我不遲到？每次遲到的都是你吧？
以上過程是一次完整的request和response。通過這個例子我們梳理出一次信息傳輸的非對稱加、解密過程：
1、消息接收方准備好公鑰和私鑰
2、私鑰接收方自己留存、公鑰發布給消息發送方
3、消息發送方使用接收方公鑰對消息進行加密
4、消息接收方用自己的私鑰對消息解密
公鑰只能用做數據加密。公鑰加密的數據，只能用對應的私鑰才能解密。這是非對稱加密的核心概念。
下面我用一個更為形象的例子來幫助大家理解。
我有下圖這樣一個信箱。
由於我只想接收我期望與之通信的朋友信件。於是我在投遞口加了一把鎖，這把鎖的鑰匙（公鑰）我可以復制n份，發給我想接受其信件的人。只有這些人可以用這把鑰匙打開寄信口，把信件投入。
相信通過這個例子，可以幫助大家徹底理解公鑰和私鑰的概念。
RSA 是現在使用最為廣泛的非對稱加密演算法，本節我們來簡單介紹 RSA 加解密的過程。
RSA 加解密演算法其實很簡單：
密文=明文^E mod N
明文=密文^D mod N
RSA 演算法並不會像對稱加密一樣，用玩魔方的方式來打亂原始信息。RSA 加、解密中使用了是同樣的數 N。公鑰是公開的，意味著 N 也是公開的。所以私鑰也可以認為只是 D。
我們接下來看一看 N、E、D 是如何計算的。
1、求 N
首先需要准備兩個很大質數 a 和 b。太小容易破解，太大計算成本太高。我們可以用 512 bit 的數字，安全性要求高的可以使用 1024，2048 bit。
N=a*b
2、求 L
L 只是生成密鑰對過程中產生的數，並不參與加解密。L 是 (a-1) 和 (b-1) 的最小公倍數
3、求 E（公鑰）
E 有兩個限制：
1<E<
E和L的最大公約數為1
第一個條件限制了 E 的取值范圍，第二個條件是為了保證有與 E 對應的解密時用到的 D。
4、求 D（私鑰）
D 也有兩個限制條件：
1<D<L
E*D mod L = 1
第二個條件確保密文解密時能夠成功得到原來的明文。
由於原理涉及很多數學知識，這里就不展開細講，我們只需要了解這個過程中用到這幾個數字及公式。這是理解RSA 安全性的基礎。
由於 N 在公鑰中是公開的，那麼只需要破解 D，就可以解密得到明文。
在實際使用場景中，質數 a,b 一般至少1024 bit，那麼 N 的長度在 2048 bit 以上。D 的長度和 N 接近。以現在計算機的算力，暴力破解 D 是非常困難的。
公鑰是公開的，也就是說 E 和 N 是公開的，那麼是否可以通過 E 和 N 推斷出 D 呢？
E*D mod L = 1
想要推算出 D 就需要先推算出 L。L 是 (a-1) 和 (b-1) 的最小公倍數。想知道 L 就需要知道質數 a 和 b。破解者並不知道這兩個質數，想要破解也只能通過暴力破解。這和直接破解 D 的難度是一樣的。
等等，N 是公開的，而 N = a*b。那麼是否可以對 N 進行質因數分解求得 a 和 b 呢？好在人類還未發現高效進行質因數分解的方法，因此可以認為做質因數分解非常困難。
但是一旦某一天發現了快速做質因數分解的演算法，那麼 RSA 就不再安全
我們可以看出大質數 a 和 b 在 RSA 演算法中的重要性。保證 a 和 b 的安全也就確保了 RSA 演算法的安全性。a 和 b 是通過偽隨機生成器生成的。一旦偽隨機數生成器的演算法有問題，導致隨機性很差或者可以被推斷出來。那麼 RSA 的安全性將被徹底破壞。
中間人攻擊指的是在通信雙方的通道上，混入攻擊者。他對接收方偽裝成發送者，對放送放偽裝成接收者。
他監聽到雙方發送公鑰時，偷偷將消息篡改，發送自己的公鑰給雙方。然後自己則保存下來雙方的公鑰。
如此操作後，雙方加密使用的都是攻擊者的公鑰，那麼後面所有的通信，攻擊者都可以在攔截後進行解密，並且篡改信息內容再用接收方公鑰加密。而接收方拿到的將會是篡改後的信息。實際上，發送和接收方都是在和中間人通信。
要防範中間人，我們需要使用公鑰證書。這部分內容在下一篇文章里會做介紹。
和對稱加密相比較，非對稱加密有如下特點：
1、非對稱加密解決了密碼配送問題
2、非對稱加密的處理速度只有對稱加密的幾百分之一。不適合對很長的消息做加密。
3、1024 bit 的 RSA不應該在被新的應用使用。至少要 2048 bit 的 RSA。
RSA 解決了密碼配送問題，但是效率更低。所以有些時候，根據需求可能會配合使用對稱和非對稱加密，形成混合密碼系統，各取所長。
最後提醒大家，RSA 還可以用於簽名，但要注意是私鑰簽名，公鑰驗簽。發信方用自己的私鑰簽名，收信方用對方公鑰驗簽。關於簽名，後面的文章會再詳細講解。