限于篇幅,我們在這一節僅討論應用層中有關電子郵件的安全協議。LMX2306TMD電子郵件在傳送過程中可能要經過許多路由器,其中的任何一個路由器都有可能對轉發的郵件進行閱讀。從這個意義上講,電子郵件是沒有什么隱私可言的。

   電子郵件這種網絡應用也有其很特殊的地方,這就是發送電子郵件是個即時的行為。這種行為在本質上與我們前兩節所討論的不同。當我們使用IPSec或SSL時,我們假設雙方在相互之間建立起一個會話并雙向地交換數據。而在電子郵件中沒有會話存在。當A向B發送一個電子郵件時,A和B并不會為此而建立任何會話。而在此后的某個時間,如果B讀取了該郵件,他有可能會,也有可能不會回復這個郵件。可見我們所討論的是單向報文的安全問題。

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

A可以選擇用數據加密標準DES進行加密/解密,并選擇用klD5作為報文摘要算法。當A向B發送電子郵件時,就在自己的郵件中包含與DEs和MD5相對應的標識。B在接收到該郵件后,首先要提取這些標識,然后就能知道在解密和報文摘要運算時應當分別使用哪種

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