當前位置:首頁 » 服務存儲 » 公鑰和私鑰的存儲方式
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

公鑰和私鑰的存儲方式

發布時間: 2022-09-04 22:31:34

㈠ 公鑰跟私鑰

公鑰和私鑰就是俗稱的不對稱加密方式,是從以前的對稱加密(使用用戶名與密碼)方式的提高。用電子郵件的方式說明一下原理
使用公鑰與私鑰的目的就是實現安全的電子郵件,必須實現如下目的:
1. 我發送給你的內容必須加密,在郵件的傳輸過程中不能被別人看到。
2. 必須保證是我發送的郵件,不是別人冒充我的。
要達到這樣的目標必須發送郵件的兩人都有公鑰和私鑰。
公鑰,就是給大家用的,你可以通過電子郵件發布,可以通過網站讓別人下載,公鑰其實是用來加密/驗章用的。私鑰,就是自己的,必須非常小心保存,最好加上密碼,私鑰是用來解密/簽章,首先就Key的所有權來說,私鑰只有個人擁有。公鑰與私鑰的作用是:用公鑰加密的內容只能用私鑰解密,用私鑰加密的內容只能用公鑰解密。
比如說,我要給你發送一個加密的郵件。首先,我必須擁有你的公鑰,你也必須擁有我的公鑰。
首先,我用你的公鑰給這個郵件加密,這樣就保證這個郵件不被別人看到,而且保證這個郵件在傳送過程中沒有被修改。你收到郵件後,用你的私鑰就可以解密,就能看到內容。
其次我用我的私鑰給這個郵件加密,發送到你手裡後,你可以用我的公鑰解密。因為私鑰只有我手裡有,這樣就保證了這個郵件是我發送的。
當A->B資料時,A會使用B的公鑰加密,這樣才能確保只有B能解開,否則普羅大眾都能解開加密的訊息,就是去了資料的保密性。驗證方面則是使用簽驗章的機制,A傳資料給大家時,會以自己的私鑰做簽章,如此所有收到訊息的人都可以用A的公鑰進行驗章,便可確認訊息是由 A 發出來的了。

㈡ web伺服器的私鑰保存在什麼地方

是一段代碼
如果要解除HTTP起動時的口令輸入
可以這樣:
# cd /usr/local/apache2/conf/ssl.key/
或創建 /usr/local/apache2/conf/ssl.key/sendsslpwd
此時,Web伺服器的私鑰已經沒有口令加密

㈢ 說明公鑰和私鑰各在什麼時候使用

1.公鑰和私鑰是一對經過演算法得出來的兩個文件,一個私鑰只對應一個公鑰,也就是有唯一性
密鑰的路徑:*.pkr是公鑰 而 *.skr是私鑰

2.獲得別人的公鑰可以使用PGP 軟體里的「搜索」從「keyserver.pgp.com」伺服器上找到。或者讓對方給你發一個公鑰給你。PGP一般用來發郵件較多,已經支待Out Look 或第三方郵件客戶端。發郵件時PGP會檢測到有一個會話(PGP軟體里可以設置加密方式:所有郵件,指定域名或收件人等等)他會自動查詢本地公鑰且加密發送出去。要是只發個文件的話你可以用PGP軟體里的「新建 PGP壓縮包」 加密分單獨設密碼或者用對方的公鑰加密。
3.PGP軟體界面左側:公鑰一般都在「全部密鑰」里、個人的私鑰在「我的私鑰」里。「全部密鑰」里存放的都是別人的公鑰包括你自己的,想把公鑰給別人的話在那個公鑰上」右鍵-->導出.「即可(是一個*.asc的文件)。在菜單「密鑰」里有PGP密鑰環屬性。你會看到公私鑰存放的位置。
4.發郵時件如設置後PGP會自動加密解密。發文件時在「新建 PGP壓縮包」 加密,周上第2點的後一句。私鑰不會在別人那裡,只有在自己手裡。除非你發給對方,用對方的公鑰加密文件,然後對方用自己的私鑰解密用自己公鑰加密的文件,反之對方用你的公鑰加密發給你。
5.PGP生成的是一對公私鑰是兩個文件,同上第1點。郵件加密的時候軟體自動幫你用對方的公鑰加密一般你不用管的。文件加密時注意下發給誰的用誰的公鑰加密,因為有唯一性

追問:
1.Key中已校驗選項為灰色,不是綠色的勾,請問是否有影響,如有該怎麼修正

答:發郵件肯定會有影響,國為灰色的PGP軟體不會啟用,發郵件是會提示找不到公鑰,需要你手動簽下名,右鍵灰色公鑰「sign」簽名。這種情況一般是由於對方沒有在PGP伺服器上傳後驗證或是PGP軟體的bug.
2.發送到伺服器的公鑰是跟郵箱掛鉤的,那也就可以直接攻擊郵箱後,重新製作公鑰,用製作公鑰發送到伺服器替換原本公鑰,這樣就可以冒充原公鑰,用新私鑰解密。這就不安全了啊。
答:一個私鑰只對應一個公鑰,也就是有唯一性。別忘了私鑰只在自己手裡哦。

㈣ 什麼是公鑰和私鑰

公鑰和私鑰是通過一種演算法得到的一個密鑰對(即一個公鑰和一個私鑰),將其中的一個向外界公開,稱為公鑰;另一個自己保留,稱為私鑰。通過這種演算法得到的密鑰對能保證在世界范圍內是唯一的。使用這個密鑰對的時候,如果用其中一個密鑰加密一段數據,必須用另一個密鑰解密。比如用公鑰加密數據就必須用私鑰解密,如果用私鑰加密也必須用公鑰解密,否則解密將不會成功。

㈤ 如何保護數字證書和私鑰

需要澄清的概念 一、關於私鑰的唯一性 嚴格地講,私鑰既然是世上唯一且只由主體本身持有,它就必須由主體的計算機程序來生成。因為如果在別處生成將會有被拷貝的機會。然而在實際應用上並非如此,出於某些特殊需要(例如,如果只有一份私鑰,單位的加密文件就會因為離職員工帶走私鑰而無法解密。)加密用的公/私鑰對會要求在可信的第三方儲存其備份。這樣,加密用的私鑰可能並不唯一。然而簽名用的私鑰則必須保持唯一,否則就無法保證被簽名信息的不可否認性。 在生成用戶的密鑰對時,用於加密的公/私鑰對可以由CA、RA產生,也可以在用戶終端的機器上用專用的程序(如瀏覽器程序或認證軟體)來產生。用於數字簽名的密鑰對原則上只能由用戶終端的程序自行產生,才能保證私鑰信息的私密性以及通信信息的不可否認性。 我們常常聽到有人說:保管好你的軟盤,保管好你的KEY,不要讓別人盜用你的證書。有些教科書上也這樣講。應該說,這句話是有毛病的。數字證書可以在網上公開,並不怕別人盜用和篡改。因為證書的盜用者在沒有掌握相應的私鑰的情況下,盜用別人的證書既不能完成加密通信,又不能實現數字簽名,沒有任何實際用處。而且,由於有CA對證書內容進行了數字簽名,在網上公開的證書也不怕黑客篡改。我們說,更該得到保護的是儲存在介質中的私鑰。如果黑客同時盜走了證書和私鑰,危險就會降臨。 不同的存儲介質,安全性是不同的。如果證書和私鑰儲存在計算機的硬碟里,計算機一旦受到黑客攻擊,(例如被埋置了木馬程序)證書和私鑰就可能被盜用。 使用軟盤或存儲型IC卡來保存證書和私鑰,安全性要比硬碟好一些,因為這兩種介質僅僅在使用時才與電腦相連,用完後即被拔下,證書和私鑰被竊取的可能性有所降低。但是黑客還是有機會,由於軟盤和存儲型IC卡不具備計算能力,在進行加密運算時,用戶的私鑰必須被調出軟盤或IC卡進入外部的電腦,在這個過程中就會造成一定的安全隱患。 產生公私密鑰對的程序(指令集)是智能卡生產者燒制在晶元中的ROM中的,密碼演算法程序也是燒制在ROM中。公私密鑰對在智能卡中生成後,公鑰可以導出到卡外,而私鑰則存儲於晶元中的密鑰區,不允許外部訪問。 USB Key和智能卡除了I/O物理介面不一樣以外,內部結構和技術是完全一樣的,其安全性也一樣。只不過智能卡需要通過讀卡器接到電腦的串列介面上,而USB Key通過電腦的通用串列匯流排(USB)介面直接與電腦相接。另外,USB介面的通信速度要遠遠高於串列介面的通信速度。現在出品的電腦已經把USB介面作為標准配置,而使用智能卡則需要加配讀卡器。出於以上原因,各家CA都把USB Key作為首選的證書和私鑰存儲介質而加以推廣。 為了防止USB key 不慎丟失而可能被他人盜用,不少證書應用系統在使用過程中還設置了口令認證機制。如口令輸入得不對,即使掌握了USB key,也不能登錄進入應用系統。

㈥ 誰能簡述下公鑰體制和私鑰體制的主要區別

公鑰和私鑰或者稱非對稱密鑰和對稱密鑰是密碼體制的兩種方式。私鑰體制指加解密的密鑰相同或容易推出,因此加解密的密鑰都是保密的。公鑰體制指加解密密鑰彼此無法推出,公鑰公開,私鑰保密。
由上定義可知,公鑰私鑰是兩種不同的密碼體制,而不是兩個不同的應用或兩個不同的密鑰。因此在加密和簽名應用中,公鑰私鑰均可以使用。

㈦ 四、公鑰和私鑰,加密和數字簽名

本文涉及到支付寶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的, 千萬不要覺得訂單信息的加簽過程也可以放在客戶端完成

假設我們服務端收到了來自支付寶服務端的支付結果,即: 支付結果+數字簽名

那麼我們服務端就會對支付結果進行驗簽,怎麼個驗法呢?

㈧ 公鑰 私鑰各是什麼格式的文件

公鑰和私鑰

1,公鑰和私鑰成對出現
2,公開的密鑰叫公鑰,只有自己知道的叫私鑰
3,用公鑰加密的數據只有對應的私鑰可以解密
4,用私鑰加密的數據只有對應的公鑰可以解密
5,如果可以用公鑰解密,則必然是對應的私鑰加的密
6,如果可以用私鑰解密,則必然是對應的公鑰加的密

假設一下,我找了兩個數字,一個是1,一個是2。我喜歡2這個數字,就保留起來,不告訴你們,然後我告訴大家,1是我的公鑰。

我有一個文件,不能讓別人看,我就用1加密了。別人找到了這個文件,但是他不知道2就是解密的私鑰啊,所以他解不開,只有我可以用數字2,就是我的私鑰,來解密。這樣我就可以保護數據了。

我的好朋友x用我的公鑰1加密了字元a,加密後成了b,放在網上。別人偷到了這個文件,但是別人解不開,因為別人不知道2就是我的私鑰,只有我才能解密,解密後就得到a。這樣,我們就可以傳送加密的數據了。

現在我們知道用公鑰加密,然後用私鑰來解密,就可以解決安全傳輸的問題了。如果我用私鑰加密一段數據(當然只有我可以用私鑰加密,因為只有我知道2是我的私鑰),結果所有的人都看到我的內容了,因為他們都知道我的公鑰是1,那麼這種加密有什麼用處呢?

但是我的好朋友x說有人冒充我給他發信。怎麼辦呢?我把我要發的信,內容是c,用我的私鑰2,加密,加密後的內容是d,發給x,再告訴他解密看是不是c。他用我的公鑰1解密,發現果然是c。這個時候,他會想到,能夠用我的公鑰解密的數據,必然是用我的私鑰加的密。只有我知道我得私鑰,因此他就可以確認確實是我發的東西。這樣我們就能確認發送方身份了。這個過程叫做數字簽名。當然具體的過程要稍微復雜一些。用私鑰來加密數據,用途就是數字簽名。

好,我們復習一下:
1,公鑰私鑰成對出現
2,私鑰只有我知道
3,大家可以用我的公鑰給我發加密的信了
4,大家用我的公鑰解密信的內容,看看能不能解開,能解開,說明是經過我的私鑰加密了,就可以確認確實是我發的了。

總結一下結論:
1,用公鑰加密數據,用私鑰來解密數據
2,用私鑰加密數據(數字簽名),用公鑰來驗證數字簽名。

在實際的使用中,公鑰不會單獨出現,總是以數字證書的方式出現,這樣是為了公鑰的安全性和有效性。

數字證書的原理

數字證書採用公鑰體制,即利用一對互相匹配的密鑰進行加密、解密。每個用戶自己設定一把特定的僅為本人所知的私有密鑰(私鑰),用它進行解密和簽名;同時設定一把公共密鑰(公鑰)並由本人公開,為一組用戶所共享,用於加密和驗證簽名。當發送一份保密文件時,發送方使用接收方的公鑰對數據加密,而接收方則使用自己的私鑰解密,這樣信息就可以安全無誤地到達目的地了。通過數字的手段保證加密過程是一個不可逆過程,即只有用私有密鑰才能解密. 在公開密鑰密碼體制中,常用的一種是RSA體制。
用戶也可以採用自己的私鑰對信息加以處理,由於密鑰僅為本人所有,這樣就產生了別人無法生成的文件,也就形成了數字簽名。採用數字簽名,能夠確認以下兩點:
(1)保證信息是由簽名者自己簽名發送的,簽名者不能否認或難以否認;
(2)保證信息自簽發後到收到為止未曾作過任何修改,簽發的文件是真實文件。

我的解釋:

每個用戶都有一對私鑰和公鑰。
私鑰用來進行解密和簽名,是給自己用的。
公鑰由本人公開,用於加密和驗證簽名,是給別人用的。

當該用戶發送文件時,用私鑰簽名,別人用他給的公鑰解密,可以保證該信息是由他發送的。即數字簽名。
當該用戶接受文件時,別人用他的公鑰加密,他用私鑰解密,可以保證該信息只能由他接收到。可以避免被其他人看到。

數字證書

是數字形式的標識,與護照或駕駛員執照十分相似。數字證書是數字憑據,它提供有關實體標識的信息以及其他支持信息。數字證書是由成為證書頒發機構(CA)的權威機構頒發的。由於數字證書有證書權威機構頒發,因此由該權威機構擔保證書信息的有效性。此外,數字證書只在特定的時間段內有效。

數字證書包含證書中所標識的實體的公鑰(就是說你的證書里有你的公鑰),由於證書將公鑰與特定的個人匹配,並且該證書的真實性由頒發機構保證(就是說可以讓大家相信你的證書是真的),因此,數字證書為如何找到用戶的公鑰並知道它是否有效這一問題提供了解決方案。

綜上所述,公鑰 私鑰都是保存在數字證書之中的,並不以單獨的文件格式存在.

㈨ 計算機密碼學中的公鑰和私鑰以及加密密鑰和解密密鑰之間什麼關系

密碼是你可以在鍵盤上輸入的字元,但密鑰是指一種硬體,常被稱為加密狗,簡稱狗。密鑰是要接在電腦主機後面的,通過硬體來解密。 公鑰和私鑰或者稱非對稱密鑰和對稱密鑰是密碼體制的兩種方式。私鑰體制指加解密的密鑰相同或容易推出,因此加解密的密鑰都是保密的。公鑰體制指加解密密鑰彼此無法推出,公鑰公開,私鑰保密。
由上定義可知,公鑰私鑰是兩種不同的密碼體制,而不是兩個不同的應用或兩個不同的密鑰。因此在加密和簽名應用中,公鑰私鑰均可以使用。