限于篇幅,我們在這一節(jié)僅討論應(yīng)用層中有關(guān)電子郵件的安全協(xié)議。LMX2306TMD電子郵件在傳送過程中可能要經(jīng)過許多路由器,其中的任何一個(gè)路由器都有可能對轉(zhuǎn)發(fā)的郵件進(jìn)行閱讀。從這個(gè)意義上講,電子郵件是沒有什么隱私可言的。

   電子郵件這種網(wǎng)絡(luò)應(yīng)用也有其很特殊的地方,這就是發(fā)送電子郵件是個(gè)即時(shí)的行為。這種行為在本質(zhì)上與我們前兩節(jié)所討論的不同。當(dāng)我們使用IPSec或SSL時(shí),我們假設(shè)雙方在相互之間建立起一個(gè)會(huì)話并雙向地交換數(shù)據(jù)。而在電子郵件中沒有會(huì)話存在。當(dāng)A向B發(fā)送一個(gè)電子郵件時(shí),A和B并不會(huì)為此而建立任何會(huì)話。而在此后的某個(gè)時(shí)間,如果B讀取了該郵件,他有可能會(huì),也有可能不會(huì)回復(fù)這個(gè)郵件�？梢娢覀兯懻摰氖菃蜗驁�(bào)文的安全問題。

   如果說電子郵件是即時(shí)的行為,那么發(fā)送方與接收方如何才能就用于電子郵件安全的加密算法達(dá)成一致意見呢?如果雙方之間不存在會(huì)話,不存在協(xié)商加密/解密所使用的算法,那么接收方如何知道發(fā)送方選擇了哪種算法呢?要解決這個(gè)問題,電子郵件的安全協(xié)議就應(yīng)當(dāng)為每種加密操作定義相應(yīng)的算法,以便用戶在其系統(tǒng)中使用。A必須要把使用的算法的名稱(或標(biāo)識)包含在電子郵件中。例如。

A可以選擇用數(shù)據(jù)加密標(biāo)準(zhǔn)DES進(jìn)行加密/解密,并選擇用klD5作為報(bào)文摘要算法。當(dāng)A向B發(fā)送電子郵件時(shí),就在自己的郵件中包含與DEs和MD5相對應(yīng)的標(biāo)識。B在接收到該郵件后,首先要提取這些標(biāo)識,然后就能知道在解密和報(bào)文摘要運(yùn)算時(shí)應(yīng)當(dāng)分別使用哪種

算法了。加密算法在使用加密密鑰時(shí)也存在同樣的問題。如果沒有協(xié)商過程,通信的雙方如何在彼此之間知道所使用的密鑰?目前的電子郵件安全協(xié)議要求使用對稱密鑰算法進(jìn)行加密和解密,并且這個(gè)一次性的密鑰要跟隨報(bào)文一起發(fā)送。發(fā)信人A可以生成一個(gè)密鑰并把它與報(bào)文一起發(fā)送給B。為了保護(hù)密鑰不被外人截獲,這個(gè)密鑰需要用收信人B的公鑰進(jìn)行加密。總之,這個(gè)密鑰本身也要被加密。