2009-07-29 64 views
1

我似乎在這裏有誤解。DSACryptoServiceProvider與RSACryptoServiceProvider

我需要使用數字簽名來實現公鑰/私鑰加密(PKCS)。我在.Net框架中找到了以下類。

  1. 的RSACryptoServiceProvider
  2. DSACryptoServiceProvider

我想那麼數字對文件進行加密他們簽名,並在接收驗證簽名,然後解密。

DSACryptoServiceProvider類具有VerifySignature函數,它可以同時使用帶符號的有符號值和無符號值!

我在這裏的問題是加密 - 然後簽名或簽名後加密?

如果我發送的加密密鑰的未簽名的密鑰(與簽署密鑰一起),然後任何第三方將能夠解密文本

回答

1

簽名意味着:

  1. 發件人計算髮送

  2. 發件人之前,從數據的散列進行加密該散列與發件人私鑰

  3. 接收機從接收到的數據來計算散列

  4. 接收方用發件人公鑰解密發件人簽名

  5. 接收機比較本地計算的散列和所解密的簽名

我想VerifySignature()不4)和5)

在步驟1)和3)創建散列步驟加密或未加密的數據,只要發件人和收件人完全一樣,您就可以選擇。

請注意,這與數據的實際加密無關,您甚至可以對未加密的數據進行簽名。還要注意,密鑰的使用是相反的,通常您使用接收方公鑰加密。

0

你總是加密後再簽收。這樣做意味着接收方可以檢查傳輸過程中未加密的數據,而不必解密,這可能是一個漫長的過程。

+0

我完全同意,但如何使用具有函數VerifySignature(signedHash,unsignedHash)的DSACryptoServiceProvider實現此?無論如何,這裏的散列是什麼?它是加密的關鍵嗎? – ala 2009-07-29 12:09:36

+3

這是錯的。如果您需要不可否認性,那麼您實際上必須對該消息進行簽名,然後對其進行加密。否則攻擊者可能會生成他的公鑰/密鑰對,這樣解密簽名的消息就會導致攻擊者選擇的明文。 – Accipitridae 2009-07-29 18:43:03

0

只是爲了澄清一些可能的混淆(但也許這是顯而易見的):

  1. 不加密使用非對稱算法的消息本身 - 類似AES可能是比較合適的。
  2. 您發送加密的消息和散列(散列被加密)。收件人自己生成散列並檢查它是否與您發送的散列相匹配(它們使用發件人公鑰解密)。

如果你沒有一個共享密鑰的對稱加密使用(即消息本身的加密),那麼你或許應該產生一個與接收者的公鑰進行加密,並隨着發送簽名的消息。

相關問題