1.名詞解釋

• 數(shù)字簽名：在ISO7498-2標(biāo)準(zhǔn)中定義為："附加在數(shù)據(jù)單元上的一些數(shù)據(jù)重斑，或是對(duì)數(shù)據(jù)單元所作的密碼變換呜魄，這種數(shù)據(jù)和變換允許數(shù)據(jù)單元的接收者用以確認(rèn)數(shù)據(jù)單元來源和數(shù)據(jù)單元的完整性役首，并保護(hù)數(shù)據(jù)虫啥，防止被人（例如接收者）進(jìn)行偽造"。
• PKCS#7：也叫做加密消息的語法標(biāo)準(zhǔn)坑赡，由RSA安全體系在公鑰加密系統(tǒng)中交換數(shù)字證書產(chǎn)生的一種加密標(biāo)準(zhǔn)烙如。PKCS#7描述數(shù)字證書的語法和其他加密消息——尤其是，數(shù)據(jù)加密和數(shù)字簽名的方法垮衷，也包含了算法厅翔。當(dāng)使用PKCS#7進(jìn)行數(shù)字簽名時(shí)，結(jié)果包含簽名證書（一列相關(guān)證書撤回列表）和已證明路徑上任何其他證書搀突。如果使用PKCS#7加密數(shù)據(jù)刀闷，通常包含發(fā)行者的參考消息和證書的序列號(hào)，它與用于解密已加密數(shù)據(jù)的公共密鑰相關(guān)仰迁。

2.PKCS#7標(biāo)準(zhǔn)定義

• 數(shù)據(jù)：字節(jié)或8位元組串甸昏。

• 簽名設(shè)計(jì)：隨加密數(shù)據(jù)摘要一起的數(shù)據(jù)。一個(gè)信息摘要是一個(gè)哈希算法的結(jié)果（術(shù)語摘要和散列是相同定義的）徐许。使用信息摘要保證原始消息在傳輸過程中沒有被篡改施蜜，并確認(rèn)發(fā)送者的身份。

• 封裝數(shù)據(jù)：密文加上公鑰能夠解密數(shù)據(jù)雌隅。用這種方法保持消息內(nèi)容對(duì)所有人保密翻默，都是信任收件人。

• 簽名和加密數(shù)據(jù)：有公鑰的加密內(nèi)容和雙重加密的消息摘要恰起。

• 摘要數(shù)據(jù)：數(shù)據(jù)加上消息摘要修械。

• 單獨(dú)的加密數(shù)據(jù)：在這種情況，加密數(shù)據(jù)的公鑰必須通過其他機(jī)制傳輸检盼。

3.類型

1.CertificateRevocationList

CertificateRevocationLists 類型給定一個(gè)證書撤銷列表的集合肯污。它表示集合中包含足夠的信息來決定集合中的證書是否是”hot listed”的，但是可能有多于必要的證書撤銷列表吨枉，也可能少于必要的蹦渣。

CertificateRevocationLists::= SET OF CertificateRevocationList

2.ContentEncryptionAlgorithmIdentifier

ContentEncryptionAlgorithmIdentifier類型確定一個(gè)內(nèi)容加密算法比如DES。一個(gè)內(nèi)容加密算法支持加密和解密操作貌亭。加密操作用一個(gè)內(nèi)容加密密鑰把一個(gè)8位字節(jié)串（消息）映射為另一個(gè)8位字節(jié)串（密文）柬唯。解密操作和加密操作相反。由上下文確定使用哪 個(gè)操作圃庭。

ContentEncryptionAlgorithmIdentifier::= AlgorithmIdentifier

3.DigestEncryptionAlgorithmldentifier

DigestAlgorithmIdentifier類型確定一個(gè)消息摘要算法权逗。例如MD2和MD5美尸。一個(gè)消息摘要算法把一個(gè)8位字節(jié)串（消息）映射位另一個(gè)8位字節(jié)串（消息摘要）。

DigestAlgorithmIdentifier::= AlgorithmIdentifier

4. DigestEncryptionAlgorithmIdentifier

DigestEncryptionAlgorithmIdentifier類型確定一個(gè)摘要加密算法（可用來加密消息摘要）斟薇。 一個(gè)例子就是PKCS ＃1的rsaEncryption。一個(gè)摘要加密算法支持加密和解密操作恕酸。加密操作用一個(gè)摘要加密密鑰把一個(gè)8位字節(jié)串（消息摘要）映射為另一個(gè)8位字節(jié)串（加了密的摘要）堪滨。解密操作和加密操作相反。由上下文確定使用哪 個(gè)操作蕊温。

DigestEncryptionAlgorithmIdentifier::=  AlgorithmIdentifier

5.ExtendedCertificateOrCertificate

ExtendedCertificateOrCertificate類型指定一個(gè)PKCS #6擴(kuò)展證書或者一個(gè)X.509證書袱箱。這一類型遵循PKCS #6 第6節(jié)推薦的語法：

ExtendedCertificateOrCertificate::= CHOICE {
  certificate Certificate, -- X.509
  extendedCertificate [0] IMPLICITExtendedCertificate
}

4.通用語法

參照此標(biāo)準(zhǔn)，實(shí)體間內(nèi)容交換的通用語法在內(nèi)容上結(jié)合了一個(gè)content type义矛。 該語法應(yīng)有ASN.1類型的 ContentInfo:

ContentInfo::= SEQUENCE {
  contentType ContentType,
  content [0] EXPLICIT ANY DEFINED BYcontentType OPTIONAL }
ContentType::= OBJECT IDENTIFIER

類型ContentInfo的域有以下意義：

• contentType 簡要說明該內(nèi)容的類型发笔。它是一個(gè)對(duì)象標(biāo)識(shí)符，即它是一個(gè)由定義內(nèi)容類型的權(quán)威機(jī)構(gòu)分配的唯一整數(shù)串凉翻。這一標(biāo)準(zhǔn)定義了六種內(nèi)容類型：(見Section14): data, signedData,envelopedData, signedAndEnvelopedData, digestedData, 和 encryptedData了讨。

• content就是內(nèi)容. 域是可選的，如果該域不存在制轰，它的intended value一定由其他方式給出前计。它的類型和contentType的對(duì)象標(biāo)識(shí)符一起定義。

  注：當(dāng)一個(gè)ContentInfo值是諸如signed-data垃杖、signed-and-enveloped-data男杈、或者digested-data的內(nèi)部內(nèi)容,一個(gè)消息摘要算法就應(yīng)用于該內(nèi)容的DER編碼的字節(jié)上。當(dāng)一個(gè)ContentInfo值是enveloped-data或signed-and-enveloped-data 的內(nèi)部內(nèi)容,一個(gè)內(nèi)容加密算法就應(yīng)用于該內(nèi)容的定長BER編碼的字節(jié)上调俘。

  ?

5.Signed-data 內(nèi)容類型

signed-data內(nèi)容類型由任意類型的內(nèi)容和加密的（0或多個(gè)簽名者）消息摘要組成

標(biāo)準(zhǔn)應(yīng)用：

• 表示一個(gè)簽名者對(duì)該內(nèi)容類型數(shù)據(jù)的數(shù)字簽名
• 發(fā)布證書和crl

簽名數(shù)據(jù)的產(chǎn)生過程有如下幾步：

• 對(duì)于每一個(gè)簽名者伶棒，他用自己的消息摘要算法計(jì)算出摘要值
• 對(duì)于每一個(gè)簽名者，消息摘要和相關(guān)的信息用自己的私鑰加密
• 對(duì)于每一個(gè)簽名者彩库，把加密的消息摘要和其他的簽名者特定信息放入SignerInfo值中肤无。每個(gè)簽名者的證書、crl以及那些并不對(duì)應(yīng)任何簽名者的信息也在這一步被收集進(jìn)來侧巨。
• 把所有簽名者的信息摘要算法舅锄、他們的SignerInfo值和內(nèi)容一起放進(jìn)SignedData值中。

5.1SignedData類型

? signed-data內(nèi)容類型應(yīng)該是ASN.1 類型的 SignedData:

SignedData::= SEQUENCE {
  version Version,//1
  digestAlgorithmsDigestAlgorithmIdentifiers,
  contentInfo ContentInfo,
  certificates
      [0]IMPLICIT ExtendedCertificatesAndCertificates
       OPTIONAL,
  crls
    [1] IMPLICITCertificateRevocationLists OPTIONAL,
  signerInfos SignerInfos 
  }
DigestAlgorithmIdentifiers::=
  SET OF DigestAlgorithmIdentifier

SignerInfos::= SET OF SignerInfo

類型SignedData的域有以下幾點(diǎn)意義:

• version是指語法的版本號(hào)司忱，這一標(biāo)準(zhǔn)中版本應(yīng)該為1 皇忿。

• digestAlgorithms是消息摘要算法標(biāo)識(shí)符的集合。 可以包含任意數(shù)量的元素坦仍，包括0鳍烁。每一個(gè)元素標(biāo)識(shí)一種消息摘要算法（和任何相應(yīng)的參數(shù)），內(nèi)容就是用某個(gè)簽名者的算法進(jìn)行摘要運(yùn)算的繁扎。該集合旨在（以任何順序）列出所有簽名者使用的消息摘要算法以方便one-pass簽名驗(yàn)證幔荒。這一消息摘要處理過程在Section 9.3中有描述糊闽。

• contentInfo是被簽名內(nèi)容。它可以包含任意一種定義了的內(nèi)容類型爹梁。

• certificates是PKCS＃6擴(kuò)展證書和X.509證書的集合右犹。它表示集合足以包含從可識(shí)別的“根”或“頂級(jí)CA”到signerInfo域中所有簽名者的證書鏈∫可能有多于必要的證書念链，并且可能有足夠的證書來包含鏈（從兩個(gè)或多個(gè)獨(dú)立的頂級(jí)CA）。 也可能有少于必要的證書积糯，比如驗(yàn)證簽名有一個(gè)替換的方法來獲得必要的證書(e.g., 從一個(gè)先前證書集合中)掂墓。

• crls是證書撤銷列表的集合。它表示集合包含足夠的信息來決定certificates域中的證書是否是“hot listed”的看成，但這不是必須的君编。 可能有多于必要的crl,也可能有少于必要的crl。
• signerInfos是每個(gè)簽名者信息的集合川慌。其中可有任意數(shù)量的元素吃嘿，包括0。

5.2 SignerInfo 類型

每個(gè)簽名者的信息都早SignerInfo中呈現(xiàn)

SignerInfo::= SEQUENCE {
  version Version,//是指語法的版本號(hào)窘游，這一標(biāo)準(zhǔn)中版本應(yīng)該為1 
  issuerAndSerialNumberIssuerAndSerialNumber,
  digestAlgorithmDigestAlgorithmIdentifier,
  authenticatedAttributes
    [0] IMPLICIT Attributes OPTIONAL,
  digestEncryptionAlgorithm
    DigestEncryptionAlgorithmIdentifier,//標(biāo)識(shí)用簽名者私鑰加密消息摘要和相關(guān)信息的摘要加密算法
  encryptedDigest EncryptedDigest,//是用簽名者私鑰加密消息摘要和相關(guān)信息后的結(jié)果
  unauthenticatedAttributes//是不被簽名者簽名（i.e.鑒別的）的屬性的集合
    [1] IMPLICIT Attributes OPTIONAL }

EncryptedDigest::= OCTET STRING

• issuerAndSerialNumber通過頒發(fā)者的可辨別名和頒發(fā)序列號(hào)來指定簽名者的證書(及簽名者的可辨別名和公鑰)唠椭。
• digestAlgorithm指定對(duì)內(nèi)容和待鑒別屬性(若存在的話)進(jìn)行摘要計(jì)算的信息摘要算法(及相應(yīng)的參數(shù))。它應(yīng)該存在于高級(jí)SignerInfo值的digestAlgorithms域中忍饰。信息摘要的處理在Section9.3中描述贪嫂。
• authenticatedAttributes是經(jīng)由簽名者簽名（i.e.鑒別的）的屬性的集合。 該域是可選的艾蓝，但是當(dāng)被簽名的ContentInfo的content type不是data類型時(shí)該域必須存在力崇。如果該域存在，它必須包含至少兩個(gè)屬性：
  1. PKCS #9 content-type 屬性赢织，當(dāng)ContentInfo的content type值被簽名時(shí)亮靴。

1. PKCS #9 message-digest 屬性，當(dāng)值是內(nèi)容的消息摘要時(shí)(見下面)于置。

建議在PKCS實(shí)現(xiàn)中僅產(chǎn)生版本1的SignedData 值茧吊。既然版本0兼容的PEM簽名方法已廢棄，建議PKCS實(shí)現(xiàn)僅接受版本1的SignedData 值八毯。

5.3 消息摘要處理

初始的輸入是ContentInfo的content域中的DER編碼的內(nèi)容字節(jié)搓侄。僅僅是該域的DER編碼的內(nèi)容字節(jié)進(jìn)行摘要計(jì)算，而不包括 identifier字節(jié)或length字節(jié)话速。

消息摘要依賴于authenticatedAttributes域是否存在讶踪。當(dāng)該域不存在時(shí)，結(jié)果就是內(nèi)容的消息摘要值泊交。然而當(dāng)該域存在時(shí)乳讥，結(jié)果是包含authenticatedAttributes中的屬性值的完全DER編碼的消息摘要柱查。既然Attributes值必須當(dāng)作和內(nèi)容的content type、消息摘要一樣的屬性被包含云石，那些值就間接的包含在結(jié)果中唉工。

當(dāng)待簽名內(nèi)容的content type是data且authenticatedAttributes域不存在時(shí)僅該數(shù)據(jù)的值(e.g.，文件的內(nèi)容)進(jìn)行摘要計(jì)算留晚。這樣有一個(gè)優(yōu)點(diǎn)酵紫，就是在加密處理前無需知道待簽名的內(nèi)容的長度。這個(gè)方法和PEM兼容错维。

5.4摘要加密的處理

• 輸入：消息摘要處理的結(jié)果和摘要算法標(biāo)識(shí)符(或object identifier)。

• 加密密鑰：簽名者的私鑰

• 結(jié)果密鑰對(duì)DigestInfo類型值的BER編碼

  DigestInfo::= SEQUENCE {
    digestAlgorithmDigestAlgorithmIdentifier,
    digest Digest }
  Digest::= OCTET STRING
  

• digestAlgorithm標(biāo)識(shí)用來計(jì)算內(nèi)容和鑒別屬性的摘要的消息摘要算法（和相應(yīng)的參數(shù)）橄唬。它應(yīng)該和SignerInfo的digestAlgorithm 域有同樣的值赋焕。

• digest是消息摘要處理的結(jié)果。

  ---

  ?

6.Enveloped-data 內(nèi)容類型

6.1 組成

? 加密內(nèi)容和加密的一個(gè)或者多個(gè)接收者的內(nèi)容加密密鑰組成仰楚。

6.2 組建過程

• 隨機(jī)產(chǎn)生一個(gè)對(duì)應(yīng)于特定對(duì)稱加密算法的內(nèi)容加密密鑰K1
• 用K1加密內(nèi)容得到密文E
• 用接收者的公鑰對(duì)k進(jìn)行機(jī)密得到隆判。
• 對(duì)與每一個(gè)接受者將K2和接受者的其他信息放入Recipientinfo
• 將所有接收者的RecipientInfo值和密文E放入EnvelopedData值中。

6.3 Envelop-data 類型

EnvelopedData::= SEQUENCE {
  version Version,
  recipientInfos RecipientInfos,// 每個(gè)接收者信息的集合
  encryptedContentInfo EncryptedContentInfo //密文
}
RecipientInfos::= SET OF RecipientInfo

EncryptedContentInfo::= SEQUENCE {
  contentType ContentType,//指示內(nèi)容的類型
  contentEncryptionAlgorithm  ContentEncryptionAlgorithmIdentifier,
  encryptedContent  [0] IMPLICIT EncryptedContentOPTIONAL //標(biāo)識(shí)內(nèi)容加密算法
}
EncryptedContent::= OCTET STRING

6.4RecipientInfo類型

每個(gè)接收者信息用RecipientInfo類型表示:

RecipientInfo::= SEQUENCE {
  version Version,
  issuerAndSerialNumber IssuerAndSerialNumber,//通過特定的號(hào)碼和數(shù)字指定受者的證書
  //指定用接收者公鑰加密內(nèi)容加密密鑰的密鑰加密算法
  keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
  encryptedKey EncryptedKey //被接受者加密密鑰加密后的內(nèi)容密鑰
}
EncryptedKey::= OCTET STRING

7.Signed-and-enveloped-data 內(nèi)容類型

7.1 組成

• 由任意類型的加密內(nèi)容僧界、加了密的一個(gè)/多個(gè)接收者的內(nèi)容加密密鑰和雙重加密的一個(gè)/多個(gè)簽名者的消息摘要侨嘀。
• “雙重加密”由簽名者私鑰的加密和內(nèi)容加密密鑰的加密組成。

7.2 組件過程

• 隨機(jī)產(chǎn)生一個(gè)對(duì)應(yīng)于特定加密算法的內(nèi)容加密密鑰k1

• 內(nèi)容加密密鑰用每個(gè)接受者的公鑰加密得到捂襟，密鑰k2

• 對(duì)與每一個(gè)接受者將K2和接受者的其他信息放入Recipientinfo

• 對(duì)于每一個(gè)簽名者咬腕，他用自己的消息摘要算法計(jì)算出摘要值 (如果兩個(gè)簽名者使用同樣的算法，那么摘要值只需計(jì)算一次) 葬荷。

• 對(duì)于每一個(gè)簽名者涨共，消息摘要S和相關(guān)的信息用自己的私鑰加密得到Sp，結(jié)果再用k1加密得到SE

• 對(duì)于每一個(gè)簽名者宠漩，把雙重加密的消息摘要和其他的簽名者特定信息放入SignerInfo值中

• 用k1加密原文P得到密文E

• 把所有簽名者的消息摘要算法举反、所有簽名者的SignerInfo值、所有接收者的RecipientInfo值和密文E一起放入SignedAndEnvelopedData

  7.2.3打開信封并驗(yàn)證簽名

  • 用接收者的私鑰解密鑰K2得到密鑰K1扒吁，并用內(nèi)容加密密鑰K1解開加密的內(nèi)容得到原文P火鼻。
  • 每個(gè)簽名者雙重加密的消息摘要SE用K1解得到SP，結(jié)果再用簽名者公鑰解密Sp得到摘要S雕崩，恢復(fù)的消息摘要S再和獨(dú)立計(jì)算的消息摘要進(jìn)行比較魁索。

  注: signed-data和enveloped-data內(nèi)容類型有序結(jié)合通常比SignedAndEnvelopedData 更情愿被使用，除非有意考慮PEM加密處理的兼容性晨逝。

7.3 SignedAndEnvelopedData 類型

SignedAndEnvelopedData::= SEQUENCE {
  version Version,// 1
  recipientInfos RecipientInfos, //
  digestAlgorithmsDigestAlgorithmIdentifiers,//消息摘要算法標(biāo)識(shí)符的集合
  encryptedContentInfoEncryptedContentInfo,//加密內(nèi)容
  //PKCS＃6擴(kuò)展證書何X509證書的集合
  certificates   [0]IMPLICIT ExtendedCertificatesAndCertificates OPTIONAL,
  //是證書撤銷列表的集合
  crls  [1] IMPLICIT CertificateRevocationListsOPTIONAL,
  signerInfos SignerInfos   //每個(gè)簽名者信息集合
  }

注：摘要處理過程中都沒使用DER編碼

8. Digested-data內(nèi)容類型

8.1 組成

? digested-data內(nèi)容類型由任意類型的內(nèi)容和內(nèi)容的消息摘要組成蛾默。

8.2 組建過程

• 使用消息摘要算法對(duì)內(nèi)容計(jì)算摘要
• 把消息摘要算法、消息摘要和內(nèi)容放入DigestdData中.

  DigestedData::= SEQUENCE {
  version Version,
  digestAlgorithmDigestAlgorithmIdentifier,//標(biāo)識(shí)對(duì)內(nèi)容進(jìn)行摘要計(jì)算的消息摘要算法
  contentInfo ContentInfo,//對(duì)其進(jìn)行摘要計(jì)算的內(nèi)容捉貌≈ЪΓ可以是任意定義的內(nèi)容類型冬念。
  digest Digest // digest是消息摘要計(jì)算的結(jié)果。
  }  
Digest::= OCTET STRINGD

9.Encrypted-data內(nèi)容類型

encrypted-data內(nèi)容類型由任意類型的加密內(nèi)容組成牧挣。 encryptedContentInfo是加了密的內(nèi)容信息

EncryptedData::= SEQUENCE {
  version Version,// version是指語法的版本號(hào)急前，這一標(biāo)準(zhǔn)中版本應(yīng)該為0。
  encryptedContentInfoEncryptedContentInfo// encryptedContentInfo是加了密的內(nèi)容信息
  }

9.數(shù)字簽名與數(shù)字信封

1. 數(shù)字簽名

指用戶利用自己的私鑰對(duì)原始數(shù)據(jù)的哈希摘要進(jìn)行加密所得的數(shù)據(jù)瀑构。數(shù)字簽名定義兩種互補(bǔ)的運(yùn)算：一種用于簽名裆针，另一個(gè)用于驗(yàn)證。“私鑰簽名寺晌，公鑰驗(yàn)證”世吨。

簽名：發(fā)送方用特殊的hash算法，由明文中產(chǎn)生固定長度的【摘要】呻征，然后利用自己的私鑰對(duì)形成的摘要進(jìn)行加密耘婚，這里加密后的數(shù)據(jù)就是數(shù)字簽名。

驗(yàn)證：接受方利用發(fā)送方的公鑰解密被加密的摘要得到結(jié)果A陆赋，然后對(duì)明文也進(jìn)行hash操作產(chǎn)生摘要B.最后,把A和B作比較沐祷。此方式既可以保證發(fā)送方的身份正確性，又可以保證數(shù)據(jù)在傳輸過程中不會(huì)被篡改攒岛。

2.數(shù)字信封

數(shù)字信封的功能類似于普通信封赖临。普通信封在法律的約束下保證只有收信人才能閱讀信的內(nèi)容；數(shù)字信封則采用密碼技術(shù)保證了只有規(guī)定的接收人才能閱讀信息的內(nèi)容灾锯。

數(shù)字信封中采用了單鑰加密體制和公鑰密碼體制兢榨。信息發(fā)送者首先利用隨機(jī)產(chǎn)生的【對(duì)稱密碼】加密信息(因?yàn)榉菍?duì)稱加密技術(shù)的速度比較慢)，再利用接收方的【公鑰】加密對(duì)稱密碼挠进，被公鑰加密后的對(duì)稱密鑰被稱之為數(shù)字信封色乾。在傳遞信息時(shí)，信息接收方要解密信息時(shí)领突，必須先用自己的私鑰解密數(shù)字信封暖璧，得到對(duì)稱密碼，才能利用對(duì)稱密碼解密所得到的信息君旦。

數(shù)字信封既發(fā)揮了對(duì)稱加密算法速度快澎办、安全性好的優(yōu)點(diǎn)，又發(fā)揮了非對(duì)稱加密算法密鑰管理方便的優(yōu)點(diǎn)金砍。

3.應(yīng)用示例

1. 為了保證信息傳送的真實(shí)性局蚀、完整性和不可否認(rèn)性，需要對(duì)要傳送的信息進(jìn)行數(shù)字加密和數(shù)字簽名恕稠。其傳送過程如下：

發(fā)送者A：

1. A準(zhǔn)備要傳送的 數(shù)字信息(明文)

2. A對(duì)數(shù)字信息(明文)進(jìn)行哈希(hash)運(yùn)算琅绅，得到一信息摘要。

3. A用自己的【私鑰(SK)】對(duì)信息摘要進(jìn)行加密得到A的數(shù)字簽名鹅巍，并將其附在數(shù)字信息上千扶。（數(shù)字簽名）

4. A隨機(jī)產(chǎn)生一個(gè)加密鑰(DES密鑰)料祠，并用此密鑰對(duì)要發(fā)送的信息(明文)進(jìn)行加密，形成密文澎羞。（對(duì)稱加密）

5. A用B的【公鑰(PK)】對(duì)剛才隨機(jī)產(chǎn)生的加密密鑰進(jìn)行加密髓绽，將加密后的DES密鑰連同密文一起傳送給B。（數(shù)字信封）

接收者B：

1. B收到A傳送過來的密文和加過密的DES密鑰妆绞，先用自己的私鑰(SK)對(duì)加密的DES密鑰進(jìn)行解密顺呕，得到DES密鑰。

2. B然后用DES密鑰對(duì)受到的密文進(jìn)行解密括饶，得到明文的數(shù)字信息株茶，然后將DES密鑰拋棄(即DES密鑰作廢)。

3. B用A的公鑰(PK)對(duì)A的數(shù)字簽名進(jìn)行解密图焰，得到信息摘要忌卤。

4. B用相同的has算法對(duì)收到的明文再進(jìn)行一次hash運(yùn)算，得到一個(gè)新的信息摘要楞泼。

5. B將收到的信息摘要和新生成的信息摘要進(jìn)行比較，如果一致笤闯，說明收到的信息沒有被修改過堕阔。

https://blog.csdn.net/kotonohaparty/article/details/6927095