不太嚴謹的概括性描述
對稱加密算法加密解密都是同一個密鑰，所以需要讓接受密文方事先知道密鑰，而事先知道的方式一般通過網絡或者預先存儲在物理機器上，網絡通信容易被獲取，所以不安全。非對稱加密算法會生成公鑰和私鑰，如果用私密對一個明文進行加密（亦稱為簽名），目的是為了證明給“拿了它的公鑰對密文解密（亦稱為驗簽）的人”知道，這段信息是發布這個公鑰的人發的；而如果用公鑰對一個明文進行加密，目的是為了證明給“這個公鑰對應的私鑰的所有者”知道，這段信息是要發給他的。- 以上兩種方法都無法無視直接地從物理上獲取密鑰/私鑰（其實貌似什么算法都沒辦法避免，但
非對稱加密算法可以無視網絡上通信上被獲取公鑰的情況） 數字簽名就是為了證明“公鑰持有人是XXX的”的一種加密驗證法。
對稱加密算法
由對稱加密算法生成，生成的數量有可能是一個，也有可能是兩個（有沒有更多的我沒了解過，這里只是代表值不一樣，但是作用依舊一樣），經常會遇到有人說，對稱加密算法生成的密鑰只有一種，是因為“對於同一段加密的明文，都可以通過任意一‘個’密鑰進行解密”
非對稱加密算法
由非對稱加密算法生成兩個，讓別人隨便獲取的稱為公鑰，不能給別人知道的是私鑰，但這兩個密鑰本質上並沒有區別（在你將這一對密鑰公布出去之前）。
因為只要這個公鑰與私鑰是同時由非對稱加密算法生成的，公鑰加密的內容，就可以被私鑰解密；私鑰加密的內容，就可以被公鑰解密。
數字簽名
例如：甲發出一條消息，其他收到這條消息的人需要確定消息發出人是不是甲。首先，甲需要公開它自己的公鑰，而其他人如何獲取“這個甲的公鑰”，這個時候就需要作為第三方的認證中心（CA）了。此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通信方式時，如何安全轉交是一件很困難的事，因此，多數瀏覽器開發商發布版本時，會事先在內部植入常用認證機關的公開密鑰。
證明發出方
而當接收方收到甲發出的“通過甲的私鑰加密的消息”以后，就可以通過這個“可信的”公鑰進行解密。同時也因為非對稱加密的唯一加解密性，所以能被這個公鑰解密的消息，也只有持有這個私鑰的人。而為了避免消息內容其實是別人隨意捏造，通常會在消息明文頭部加上這段消息的哈希值后一齊加密再發出。接收方收到以后，就可以通過檢查這段解密后的附加哈希值，是否與消息內容的實際哈希值相等，來判斷消息是否來源於甲方了。
題外：可靠加密通訊
證明“是我發的，也是要發給你的”。甲乙雙方各自生成一對非對稱加密密鑰，並且通過一定的方法，交換雙方的公鑰。當甲需要發消息給乙的時候，先將消息用甲私鑰進行加密，證明是自己發的，然后再將消息用乙公鑰進行加密，證明是發給乙的（其實順序不重要，即使是先用乙公鑰加密，再用甲私鑰加密，效果都一樣）。
同理，乙發消息給甲的操作一樣。以此來達到“可靠加密傳輸”。