① 在非對稱加密中如何實現公鑰加密，只有私鑰可以解密的原理
可以，公鑰和私鑰匙相對的,任何一個作為公鑰,則另一個就為私鑰
② 關於私鑰加密 公鑰解密
如果只是單方面採用非對稱性加密演算法,其實有兩種方式,用於不同用處.
第一種是簽名,使用私鑰加密,公鑰解密,用於讓所有公鑰所有者驗證私鑰所有者的身份並且用來防止私鑰所有者發布的內容被篡改.但是不用來保證內容不被他人獲得.
第二種是加密,用公鑰加密,私鑰解密,用於向公鑰所有者發布信息,這個信息可能被他人篡改,但是無法被他人獲得.
如果甲想給乙發一個安全的保密的數據,那麼應該甲乙各自有一個私鑰,甲先用乙的公鑰加密這段數據,再用自己的私鑰加密這段加密後的數據.最後再發給乙,這樣確保了內容即不會被讀取,也不會被篡改.
③ RSA的公鑰和私鑰到底哪個才是用來加密和哪個用來解密
其實公鑰和私鑰都可以用來加密或解密---只要能保證用A加密，就用B解密就行。至於A是公鑰還是私鑰，其實可以根據不同的用途而定。
例如說，如果你想把某個消息秘密的發給某人，那你就可以用他的公鑰加密。因為只有他知道他的私鑰，所以這消息也就只有他本人能解開，於是你就達到了你的目的。
但是如果你想發布一個公告，需要一個手段來證明這確實是你本人發的，而不是其他人冒名頂替的。那你可以在你的公告開頭或者結尾附上一段用你的私鑰加密的內容（例如說就是你公告正文的一段話），那所有其他人都可以用你的公鑰來解密，看看解出來的內容是不是相符的。如果是的話，那就說明這公告確實是你發的---因為只有你的公鑰才能解開你的私鑰加密的內容，而其他人是拿不到你的私鑰的。
最後再說一下數字簽名。
數字簽名無非就兩個目的：
證明這消息是你發的；
證明這消息內容確實是完整的---也就是沒有經過任何形式的篡改（包括替換、缺少、新增）。
其實，上面關於「公告」那段內容，已經證明了第一點：證明這消息是你發的。
那麼要做到第二點，也很簡單，就是把你公告的原文做一次哈希（md5或者sha1都行），然後用你的私鑰加密這段哈希作為簽名，並一起公布出去。當別人收到你的公告時，他可以用你的公鑰解密你的簽名，如果解密成功，並且解密出來的哈希值確實和你的公告原文一致，那麼他就證明了兩點：這消息確實是你發的，而且內容是完整的。
其實概念很簡單：
小明想秘密給小英發送消息
小英手裡有一個盒子（public key），這個盒子只有小英手裡的鑰匙（private key）才打得開
小英把盒子送給小明（分發公鑰）
小明寫好消息放進盒子里，鎖上盒子（公鑰加密）
小明把盒子寄給小英（密文傳輸）
小英用手裡的鑰匙打開盒子，得到小明的消息（私鑰解密）
假設小剛劫持了盒子，因為沒有小英的鑰匙，他也打不開
④ 怎樣實現對私鑰（公鑰）進行解密
要實現安全登錄，可以採用下面三種方法，一種基於非對稱加密演算法，一種基於對稱加密演算法，最後一種基於散列演算法。下面我們來分別討論這三種方法。
非對稱加密演算法中，目前最常用的是 RSA 演算法和 ECC（橢圓曲線加密）演算法。要採用非對稱加密演算法實現安全登錄的話，首先需要在客戶端向伺服器端請求登錄頁面時，伺服器生成公鑰和私鑰，然後將公鑰隨登錄頁面一起傳遞給客戶端瀏覽器，當用戶輸入完用戶名密碼點擊登錄時，登錄頁面中的 javaScript 調用非對稱加密演算法對用戶名和密碼用用公鑰進行加密。然後再提交到伺服器端，伺服器端利用私鑰進行解密，再跟資料庫中的用戶名密碼進行比較，如果一致，則登錄成功，否則登錄失敗。
看上去很簡單，但是這里有這樣幾個問題。目前 RSA 演算法中，1024－2048 位的密鑰被認為是安全的。如果密鑰長度小於這個長度，則認為可以被破解。但這樣的長度超過了程序設計語言本身所允許的數字運算范圍，需要通過模擬來實現大數運算。而在 Web 系統的客戶端，如果通過 JavaScript 來模擬大數運行的話，效率將會是很低的，因此要在客戶端採用這樣的密鑰來加密數據的話，許多瀏覽器會發出執行時間過長，停止運行的警告。然而，解密或者密鑰生成的時間相對於加密來說要更長。雖然解密和密鑰生成是在伺服器端執行的，但是如果伺服器端是 PHP、ASP 這樣的腳本語言的話，它們也將很難勝任這樣的工作。ECC 演算法的密鑰長度要求比 RSA 演算法要低一些，ECC 演算法中 160 位的密鑰長度被認為與 RSA 演算法中 1024 位的密鑰長度的安全性是等價的。雖然仍然要涉及的模擬大數運算，但 ECC 演算法的密鑰長度的運算量還算是可以接受的，但是 ECC 演算法比 RSA 演算法要復雜的多，因此實現起來也很困難。
對稱加密演算法比非對稱加密演算法要快得多，但是對稱加密演算法需要數據發送方和接受方共用一個密鑰，密鑰是不能通過不安全的網路直接傳遞的，否則密鑰和加密以後的數據如果同時監聽到的話，入侵者就可以直接利用監聽到的密鑰來對加密後的信息進行解密了。
那是不是就不能通過對稱加密演算法實現安全登錄呢？其實只要通過密鑰交換演算法就可以實現安全登錄了，常用的密鑰交換演算法是 Diffie-Hellman 密鑰交換演算法。我們可以這樣來實現密鑰的安全傳遞，首先在客戶端向伺服器端請求登錄頁面時，伺服器端生成一個大素數 p，它的本原根 g，另外生成一個隨機數 Xa，然後計算出 Ya = gXa mod p，將 p、g、Ya 連同登錄頁面一起發送給客戶端，然後客戶端也生成一個隨機數 Xb，計算 Yb = gXb mod p，然後再計算 K = YaXb mod p，現在 K 就是密鑰，接下來就可以用 K 作密鑰，用對稱加密演算法對用戶輸入進行加密了，然後將加密後的信息連同計算出來的 Yb 一同發送給伺服器端，伺服器端計算 K = YbXa mod p，這樣就可以得到跟客戶端相同的密鑰 K 了，最後用客戶端加密演算法的相應解密演算法，就可以在伺服器端將加密信息進行解密了，信息解密以後進行比較，一致則登錄成功，否則登錄失敗。需要注意的時候，這里伺服器端生成的隨機數 Xa 和 客戶端生成的隨機數 Xb 都不傳遞給對方。傳遞的數據只有 p、g、Ya、Yb 和加密後的數據。
但是如果我們不採用加密演算法而採用散列演算法對登錄密碼進行處理的話，可以避免被直接解密出原文，但是如果直接採用 MD5 或者 SHA1 來對登錄密碼進行處理後提交的話，一旦入侵者監聽到散列後的密碼，則不需要解密出原文，直接將監聽到的數據提交給伺服器，就可以實現入侵的目的了。而且，目前 MD5 演算法已被破解，SHA1 演算法則被證明從理論上可破解，就算採用離線碰撞，也可以找出與原密碼等價的密碼來。所以直接採用 MD5 或者 SHA1 來對密碼進行散列處理也是不可行的。
但是如果在散列演算法中加入了密鑰，情況就不一樣了。hmac 演算法正好作了這樣的事情，下面我們來看看如何用 hmac 演算法實現安全登錄。首先在客戶端向伺服器端請求登錄頁面時，伺服器端生成一個隨機字元串，連同登錄頁面一同發送給客戶端瀏覽器，當用戶輸入完用戶名密碼後，將密碼採用 MD5 或者 SHA1 來生成散列值作為密鑰，伺服器端發送來的隨機字元串作為消息數據，進行 hmac 運算。然後將結果提交給伺服器。之所以要對用戶輸入的密碼進行散列後再作為密鑰，而不是直接作為密鑰，是為了保證密鑰足夠長，而又不會太長。伺服器端接受到客戶端提交的數據後，將保存在伺服器端的隨機字元串和用戶密碼進行相同的運算，然後進行比較，如果結果一致，則認為登錄成功，否則登錄失敗。當然如果不用 hmac 演算法，直接將密碼和伺服器端生成的隨機數合並以後再做 MD5 或者 SHA1，應該也是可以的。
這里客戶端每次請求時伺服器端發送的隨機字元串都是不同的，因此即使入侵者監聽到了這個隨機字元串和加密後的提交的數據，它也無法再次提交相同的數據通過驗證。而且通過監聽到的數據也無法計算出密鑰，所以也就無法偽造登錄信息了。
對稱和非對稱加密演算法不僅適用於登錄驗證，還適合用於最初的密碼設置和以後密碼修改的過程中，而散列演算法僅適用於登錄驗證。但是散列演算法要比對稱和非對稱加密演算法效率高。
⑤ JAVA公鑰加密，私鑰解密，該怎麼解決
就是一個演算法的問題演算法生成公鑰加密然後把用私鑰解密而已
⑥ java中RSA用私鑰加密公鑰解密問題
公鑰和私鑰可以互換的用，用公鑰加密私鑰解密，用私鑰加密公鑰解密都ok，方法一樣
⑦ 含有公鑰，能不能私鑰加密，公鑰解密
公鑰是公開的沒有錯，但是不是每個人都知道公鑰，你的公鑰只給你需要的人。有了公鑰確實可以解來密碼，但是加密文件你只發給需要的人，除非他們把文件公開，否則沒有加密文件，只知道公鑰沒有用的。反過來公鑰加密，只有你能解開，所以如果拿公鑰加密文件，你是唯一能解開密碼的人，這樣很安全的。
⑧ openssl rsa 可以用私鑰加密 公鑰解密嗎
可以，私鑰加密公鑰解密是 數字簽名的工作方式
⑨ 公鑰密碼裡面，如果一方用自己的私鑰加密，解密用自己的公鑰，公鑰不是公開的嗎任何人都可以解開
信息傳輸有兩條路徑，一是信息加密，二是身份認證，你說的這種只是身法認證環節，任何人擁有了你的公鑰，都能確認是「你」發出的（因為你使用自己的私鑰加密的，這個環節叫電子簽名）。
而具體的密文的加密是使用你的公鑰加密的，只有你的私鑰可解密，其它人沒有你的私鑰，雖然收到了消息，也知道是你發出的（即前面說的身份認證過程暢通無阻），但是沒法解密，因此無法知道具體信息內容。