个人数据安全(适用于Ubuntu和Windows)

[klop]

个人数据安全 (1)：用GnuPG保护个人隐私数据


之前在Twitter上说过，打算写一个个人数据安全解决方案的系列，内容包括：

    * 基于GnuPG的个人隐私数据保护
    * 自建XMPP服务器保障即时通讯安全
    * 使用Dropbox进行较低密级的文件共享和协作

    后记：后来觉得Dropbox这个话题太简单了点，没啥好写的，且重点在共享和协作，而非安全，便取消了。

原本还打算写一写用SSH端口转发隧道建立SOCKS v5代理（俗称SSH翻墙术），鉴于网上已经有不少不错的介绍，就不再重复劳动了。这里所采用的技术全部基于开源软件、免费软件或免费服务商，同时也兼顾使用体验。除了自建XMPP服务器所需的域名费用外，其余部分的经济成本为零。

跟丫头暂时还维持着北京、杭州两地分居的状况，网络是平时联络和数据交换的最为重要的手段。上述的这些技术都是我们目前正在使用的数据安全保障手段。这几篇文章的前身其实就是我写给丫头的操作手册。内容并不艰深，丫头并非计算机专业也能轻松掌握就是最佳佐证 :-D

另外，由于我平时主要使用Ubuntu，所以这里的所有方案都同时适用于Ubuntu和Windows。对Ubuntu以外的其他Linux发行版，这里就不兼顾了，不过方法都大同小异。

第一篇挑个复杂点儿的，讲讲GnuPG 8-)

本篇将讲述Windows和Ubuntu下的GnuPG解决方案，同时也会对GnuPG背后的信息安全原理做一些简单的科普。GnuPG可用于隐私数据的加密和签名，以便对其进行安全的传输和存储。除GnuPG外，本篇介绍的软件还包括Windows下的GnuPG Shell、GPGee（GnuPG explorer extension）以及Ubuntu下的Seahorse。

对于熟悉GnuPG加密、签名原理的读者，可以直接跳过科普的章节，直接阅读软件安装配置部分。
缘由

丫头平时记性都挺好，唯独记不住密码，各种帐号密码随设随忘。我则刚好反，平时啥啥都忘，唯独对各种随机字符串印象深刻。我自己的各个密码在各大网站的密码强度评估也从来都是绿色。所以她的各种账户密码基本上都靠我来记，想不起来了就给我发个查询请求。有时候不光是密码，偶尔还需要互相备份网银、支付宝之类的证书文件。这些都属于有高保密性要求的隐私数据。

丫头虽然不是计算机专业，不过在软件应用方面还是有相当的水准，我并不太担心她的机器上会有病毒或木马。所以在一定程度上说，密码、证书被盗的概率实际上并不高。然而墙内信息安全形势之恶劣已经是众所周知，通过IM或邮件明文传输密码、证书总是件让人不放心的事情。即使我们所使用的服务都号称对通讯做了加密，但出于众所周知的原因，国内的服务商们为了自身的生存，实际上都不得不在服务器端对解密后的明文数据做内容过滤和审查。因此也就存在着恶意个体或团体有目的的盗取用户明文数据的可能。作为程序员，总有种如坐针毡的不爽，必须防患于未然。这个想法促使我去寻求一个相对严密且切实可行的保障隐私数据安全的解决方案。
问题描述

解决信息安全问题的首要任务，就是确立威胁模型。简单来说就是将现实中存在的诸多威胁信息安全的因素分门别类，找出最需要解决的威胁因素。在这里，我们假设发件人和收件人的主机都是安全的，需要处理的威胁主要是来自数据传输通路上的数据监听、窃取、篡改和仿冒。

更精确一些，数据传输过程必须提供以下保障：

   1. 保密性：发件人所发出的消息必须是加密的，且只有特定的收件人才能够对密文进行解密
   2. 完整性：发件人所发出的消息必须原封不动地抵达收件人那里，如果沿途惨遭篡改、删节，收件人必须能够发现
   3. 身份验证：收件人能够验证发件人的身份，以保证其他人不能仿冒发件人的身份发送虚假消息

加密

要保障保密性，最简单的方法莫过于使用加密压缩包（Zip、7Zip、RAR等常用压缩格式都支持加密）。然而要采用这种方法，首先要把解压密钥交到收件人手中。如何安全地交换解压密钥？这就陷入了一个死循环。

双方使用同样的密钥对数据进行加密和解密，这种加密方式被称作对称加密，对应的密钥就被称作对称密钥。常用的对称加密算法，如RC4、3DES、 AES等，都具有高效的优点，即使是普通PC机也可以在短时间内使用这些算法对大量数据进行加解密。然而它们也都不可避免地具有加解密双方必须事先共享对称密钥的先天缺陷。正是这个缺陷导致了上面鸡生蛋蛋生鸡的窘境。

相对于对称加密，非对称加密（或称公钥加密）则很好地克服了这个缺陷。非对称加密需要使用不止一个，而是一对密钥——一个公钥和一个私钥。明文数据使用公私钥对中的一个密钥加密后，只能由对应的另一个密钥解密。应用非对称加密时，用户需要妥善保管私钥，不得外泄或丢失，同时公开公钥。

借助非对称加密，保密性基本得到解决。初始时，收件人生成一对密钥，并将公钥公布给发件人。双方收发消息时遵循一下流程：

   1. 发件人用收件人的公钥加密消息，生成密文并发送给收件人
   2. 收件人用自己的私钥解密消息密文，得到消息明文

看起来不错，但还有个问题：非对称加密虽然克服了需要事先交换对称密钥的问题，但常用的非对称加密算法（如RSA）都非常慢，无法在短时间内加密较长的数据。假设我们要传输的不是密码这样的短文本，而是诸如照片等尺寸上兆的数据，上述过程就行不通了。对于这个问题，解决的方法也很简单。快速加解密是对称加密的强项，那么我们就仍然使用对称加密来对数据进行加密，转而使用非对称加密来对对称密钥进行加密。这样一来，上述过程就变成：

    * 发件人
         1. 随机生成一个对称密钥
         2. 用对称密钥加密消息明文得到消息密文
         3. 用收件人的公钥加密对称密钥得到对称密钥密文
         4. 将消息密文和对称密钥密文一并发给收件人
    * 收件人
         1. 用私钥解密对称密钥密文得到对称密钥
         2. 用对称密钥解密消息密文得到消息明文

好吧，我承认有点像绕口令，但其实还是蛮简单的 :mrgreen:
数字签名

数字签名是一种用于鉴别发件人身份的技术。它主要应用了非对称加密和消息摘要。

消息摘要是将一段任意长度的消息转化成一个固定长度的短文本串的过程。对于信息安全领域所使用的摘要算法（如常用的MD5、SHA1），极难找到具有相同摘要的两段不同的消息。因此事实上只要消息摘要相同，就可认定消息相同。

对给定消息进行数字签名的过程如下：

   1. 计算消息摘要
   2. 用自己的私钥加密消息摘要，得到数字签名
   3. 将数字签名与消息一起发送给收件人

收件人收到消息后验证数字签名的过程如下：

   1. 计算消息摘要
   2. 使用发件人的公钥解密数字签名，得到原始消息摘要
   3. 比对两个消息摘要

若二者相同，即可证明该消息确实由拥有相应私钥的发件人发出，这就达到了身份验证的目的。

注意，在校验数字签名的过程中，消息完整性也得到了保证——由于数字签名中包含原始消息的摘要值，一旦消息遭到篡改，收件人计算出的消息摘要便会有别于数字签名中的原始消息摘要，从而导致验证失败。

至此，保密性、完整性和身份验证都圆满地得到了解决。完整的数据传输过程如下：

    * 发件人
          o 对消息进行数字签名
               1. 计算消息摘要
               2. 用自己的私钥加密消息摘要，得到数字签名
          o 加密签名后的消息
               1. 随机生成一个对称密钥
               2. 用对称密钥加密消息和数字签名，得到消息密文
               3. 用收件人的公钥加密对称密钥，得到对称密钥密文
               4. 将对称密钥密文和消息密文合并后发送给收件人
    * 收件人
          o 解密
               1. 用自己的私钥解密对称密钥
               2. 用对称密钥解密消息密文得到消息明文和数字签名
          o 校验数字签名
               1. 计算消息摘要
               2. 用发件人的公钥解密数字签名，得到原始消息摘要
               3. 比对两个消息摘要

以上简要解释了加密和签名的密码学原理。它们是我们的个人数据安全解决方案中最为核心的两个操作。实际上，日常生活中很多常用的信息安全保障手段，如SSL/TLS证书、网银证书、支付宝证书等等，也都在是以这两个操作为核心的。

在实际应用中，可以根据需要对加密和签名操作进行组合，例如：

    * 只加密不签名

      对隐秘文件进行备份时可采用这种方法。因为日后读取该文件的还是你自己，所以签名与否并不重要。值得注意的是，非对称密钥的长度往往很长，一般至少在1024 bit（128字节）以上，而用户选择的对称密钥则往往只有几个或十几个字节。因此一般而言，非对称加密的强度要远远高于对称加密。
    * 只签名不加密

      通过Email向公众发布重大消息时可采用这种方法。消息内容本身是公开的，因此不用加密。数字签名则可用于校验消息来源，同时防止他人仿冒发件人身份发布虚假消息。
    * 签名且加密

      一切同时强调保密性和发件人身份验证的用例都应采用这种方法。

GnuPG

呼～经过一大段的科普，现在总算要进入正题了 :-P

GnuPG（或称GPG），全称是GNU Personal Guard，它综合了上述的加密和签名技术，可为个人隐私数据提供可靠的保护。GnuPG是GNU对OpenPGP（或简称PGP）标准（RFC 4880）的实现。GnuPG剔除了OpenPGP标准中的专利算法，是完全开放和免费的开源软件。关于OpenPGP、PGP、GnuPG的关系和区别，可以参见RFC 4880 1.1节。另外，在对数据进行加密的同时GnuPG还会顺带进行压缩。

GnuPG 软件本身虽然是跨平台的，但它只提供了一套命令行工具，对于普通用户而言操作过于繁琐。因此，各种GnuPG的图形前端被开发出来用以简化用户对隐私数据的加密、签名过程。以下分别对Windows和Ubuntu下的GnuPG图形前端的安装、配置和使用做一个简要介绍。
在Windows下使用GnuPG
软件配置

需要安装的软件如下：

   1. GnuPG

      从此处下载。GnuPG是整个解决方案的核心，提供了一系列实现加密、解密、签名、证书管理等功能的命令行工具。GnuPG Shell和GPGee都需要借助GnuPG才能工作。
   2. GnuPG  Shell

      从此处下载。GnuPG Shell是GnuPG的一个图形前端，可以较为方便地完成证书管理的工作。GnuPG Shell当然也可以用于文件的加密、解密和签名操作，但是其使用不如GPGee那样来得简单直接。

   3. GPGee

      从此处下载。GPGee全称为GPG explorer extension。它在Windows Explorer的右键菜单中增加了GPG相关的菜单项，使得用户可以非常方便地执行加密、解密和签名操作。但GPGee不提供GnuPG证书的管理功能，因此建议和GnuPG Shell配合使用。

      菜单项"Sign & Encrypt"和"Sign"的含义不言自明。菜单项"Encrypt (PK)"中的PK是Public Key（公钥）的缩写，选择该菜单项可对文件进行非对称加密（公钥加密）。相应的，"Encrypt (Symmetric)"用于对文件进行对称加密，类似于使用RAR或Zip制作加密压缩包。

如果先安装GnuPG再安装GnuPG Shell，则后者会自动检测出GnuPG的安装路径，无须另外的配置。GPGee则需要手工配置GnuPG相关路径。

在GPGee菜单项中选择"Configure"进入GPGee配置对话框，有三个文件的路径需要配置，包括：

    * GnuPG主程序 ：即GnuPG安装目录下的gpg.exe
    * 公钥密钥环：位于%APPDATA%\gnupg\pubring.gpg
    * 私钥密钥环：位于%APPDATA%\gnupg\secring.gpg

其中两个密钥环文件用于存储和管理GnuPG系统中所有已知的公钥和私钥。
生成密钥

借助GnuPG Shell可以方便地生成密钥：

    * 选择菜单项"Keys/Generate New..."，打开密钥生成向导
    * 设置新密钥的基本用户信息
    * 选择"Advanced..."，设置密钥长度和有效期
          o 密钥长度越长安全性越高，但加密、解密速度越慢。出于安全性考虑，推荐至少设置为2048。
          o 密钥在有效期之后便会失效，不能再用于加密、解密或签名操作，必须重新生成密钥。默认有效期为永久有效。出于安全性考虑，推荐设置有效期为1年。
    * 设置私钥通行码（passphrase）
          o 通行码是用于保护私钥的密码，每次使用私钥进行加密、解密、签名操作时都需要输入通行码。
          o 一旦私钥丢失，通行码将是保护私钥的最后一道屏障，因此应具备一定的长度和复杂度。

录入并确认以上信息后，GnuPG Shell便会开始生成密钥。根据用户选择的密钥长度和机器的性能，密钥生成时间从几十秒到几分钟不等。密钥生成完毕后，便可在GnuPG Shell的密钥列表中看到新密钥了。同时，你会看到新密钥有一个对应的8位的Key ID，它实际上唯一标识了新密钥的公钥。Key ID的作用将在后面提及。
公钥发布与密钥服务器

生成新密钥后，剩下的事情就是和你的朋友们互相交换公钥，然后你们便可以安全地进行数据交换了。

也许你已经意识到一个重要问题，就是公钥的发布过程可能被人做手脚：如果某人制作了一对密钥，并伪装成你的朋友来和你交换公钥，那么基于公私钥认证的整个信任体系便从根基上被瓦解了。因此，必须以某种可信的方式交换公钥——比如将公钥写在纸上交给对方。

然而非对称密钥往往有成百上千个字节那么长，将其抄到纸上或是敲到电脑里无疑是傻得要命的事情。你应该还记得刚才提到的Key ID吧？这时就是它发挥作用的时候了。如果我们把公钥都发布到一个公共的地方，然后只在纸上互相交换8位的Key ID，再用Key ID到这个公共的地方下载对应的公钥，就可以安全且方便地交换公钥了。而这个公共的地方，就是密钥服务器（Key Server）。GnuPG Shell内置了对密钥服务器的支持，可以直接向服务器发布新密钥或通过Key ID获取已经发不到服务器上的其他密钥。其使用方法也比较简单直接，这里就不赘述了。

如果你和你的朋友可以有效地互相确认身份，那么也可以在不借助密钥服务器的情况下手动导出、导入公钥来进行交换。方法是在GnuPG Shell密钥列表中选择新密钥并点击工具栏上的"导出"按钮。然后你便可以将导出的公钥文件发送给其他人，同时索要他们的公钥并导入GnuPG Shell。记住，除非你们能够有效地确认对方的身份，否则不要使用这种方式交换公钥！因为公钥文件在网络传输过程中可能被劫持和篡改。这也是为什么银行总是鼓励用户使用USB硬件证书（比如招行的U盾），因为将密钥以物理方式刻录在硬件中发布给用户在要比通过网络发送密钥安全得多，尤其是在用户随时可能处于不安全的网络中时更是如此。
在Ubuntu下使用GnuPG

Ubuntu用户很幸运，Seahorse作为一个通用的密码/密钥管理器，对GnuPG提供了良好的支持，同时也支持密钥服务器。更棒的是，Seahorse还提供了若干GNOME插件，实现了类似GPGee的右键菜单功能，算是非常整齐划一的解决方案 :-D

安装过程非常简单：

sudo aptitude install gnupg seahorse seahorse-plugins

注意生成密钥时选择PGP密钥。其他步骤和在Windows下使用GnuPG Shell基本相同，就不赘述了。
结语

OpenPGP 标准以及GnuPG作为成熟的个人隐私数据安全保障方案，已经有十多年的历史了。它们也经常被集成在邮件客户端中，为Email服务提供加密和数字签名支持。然而各种邮件客户端的PGP支持在质量和兼容性上参差不齐，用起来往往问题多多。比如我曾在Thunderbird中使用过 Enigmail，结果遇到了让人头疼不已的中文编码问题，好不容易解决后，又发现跟同事使用的Outlook、Foxmail存在兼容性问题，最终不得不放弃。尔后我又尝试在Firefox中使用FireGPG访问Gmail，更是令Firefox直接崩溃......这也是我不选择Email PGP方案转而直接采用更为通用的GnuPG的原因。

记得前几年，学校里曾经刮起过一阵互换PGP/GPG Key ID的风潮。可怜我当时连PGP/GPG为何物都不知道。不想现在却和丫头用得不亦乐乎。

最后，希望这篇拙文能够在恶劣的大环境下帮助到更多人安全地完成数据交换，也就不枉我码这么多字的辛苦了 8-)



个人数据安全 (2)：保护即时通讯隐私

一般来说，即时通讯（IM）软件都会对客户端到服务器的通讯进行加密，对用户隐私数据安全提供一定程度的保障。但也有例外，比如MSN就完全不加密。所以一些小公司将MSN作为主要IM工具是极为不明智的，借助Wireshark等简单工具对员工间甚至员工和客户间的对话内容进行监听易如反掌，极容易造成商业机密的泄漏。微软坚持使用明文MSN协议的目的让人难以捉摸，其中恐怕难免混有政治因素。使用MSN Shell插件的加密功能或者SSH隧道转发等手段，也可以不同程度地间接加密MSN通讯数据。

即使是那些号称使用加密协议的IM服务，也并不真的就百分之百地安全，在国内的网络环境下尤其如此。一直饱受质疑的QQ,自不必说，国内其他的IM运营商也多少存在类似的境况。这种行为固然可恶，但作为国内的运营商，若不如此便无法生存——饭否便是个极好的例子。即便是Google，也干出了中文版Gtalk不开启加密这样的事情来。如果不采取一些特别的措施，无论你愿不愿意，正如题图一样：The big brother is watching you!

Why?

为什么即使是采用加密协议，仍然逃不过监视？那就要先看看通讯过程中哪些内容被加密，以及是如何被加密的。各种IM系统的加密方式林林总总，有的采用标准的SSL/TLS，有的则自行打造。但总体上说大致还是脱不开SSL/TLS的主体脉络，也就是先用非对称加密交换对称密钥，再用对称密钥对链路上的数据进行加密，同时辅以身份验证。其基本原理可以参见本系列的第一篇。

通常，在发送方和接收方客户端连接到服务器时首先会和服务器协商对称密钥。之后，一条聊天消息从发送到接受大致可以分为一下几个阶段：

   1. 发送方客户端用自己的对称密钥加密明文消息并发送至服务器
   2. 服务器用和发送方客户端的对称密钥还原出明文消息
   3. 服务器用和接收方客户端的对称密钥加密明文消息并发送至接收方客户端
   4. 接收方客户端用自己的对称密钥还原出明文消息

所以，被加密的实际上是消息在服务器和客户端之间的传输链路，以防在传输过程中遭到第三方（比如GFW）监听。特别需要注意的是在第2步，消息会在服务器被还原为明文。从功能角度上说，这么做的优势很明显，运营商在服务器端可以提供更多的功能。例如Gtalk的服务器端存储聊天记录，还有QQ的聊天记录漫游，以及对spam消息进行分拣过滤等等。当然，从保护用户隐私的角度考虑，运营商是不应该将明文聊天记录泄漏出去的。然而嘛......大家都知道。
Hosted.IM——搭建自己的IM服务器

既然整个环节的漏洞出在IM运营商处，那么不妨搭建自己的IM服务器吧 :-) 这里介绍的由ProcessOne提供的Hosted.IM是一个免费的XMPP托管服务，只需要一个域名即可。提供的功能包括群组聊天、文件传输、域间互通等等，详细说明参见这里。

Hosted.IM的用户界面极精简，配置的过程很简单。首先你得在Hosted.IM上注册帐号，通过邮箱验证后，还需要在自己的域名服务商处为自己的域名配上如下的DNS条目（强烈建议使用国外的域名服务，国内的域名服务很多都不提供SRV设置入口）：

_xmpp-client._tcp.tangyali.name. IN SRV 20 0 5222 xmpp2.hosted.im.
_xmpp-client._tcp.tangyali.name. IN SRV 10 0 5222 xmpp1.hosted.im.
_xmpp-server._tcp.tangyali.name. IN SRV 10 0 5269 xmpp1.hosted.im.
_xmpp-server._tcp.tangyali.name. IN SRV 20 0 5269 xmpp2.hosted.im.
_jabber._tcp.tangyali.name. IN SRV 20 0 5269 xmpp2.hosted.im.
_jabber._tcp.tangyali.name. IN SRV 10 0 5269 xmpp1.hosted.im.
_vhreg_auth.tangyali.name. IN TXT "c500b6278e37092eb24eb71492719a7e68009ac5"

最后，添加若干用户，便可用Pidgin、Psi等支持XMPP的客户端登录使用了。

简单快捷的背后，缺点也很明显：

    * 每个域名只支持10个注册用户，适合于小范围的注重即时通讯隐私的团体交流，比如小型创业团队。好在XMPP天然支持域间互通，如果一个域名 不够用，再来几个就是。
    * 管理界面太过简洁了，实际上除了增删用户以外什么功能有没有。如果你需要更多的功能或在一个域内支持更多的用户帐号，就得给ProcessOne发邮件申请付费服务了。
    * 采用这种做法，事实上并没有改变问题的本质，只是做了一个风险转移。前提是我们假设将IM服务托管在身处墙外的、相对小众的ProcessOne的风险要远小于国内的IM服务商。

ProcessOne

顺便说一说ProcessOne。可能很多人都没有听说过这家公司，但在Erlang和XMPP界，ProcessOne可是鼎鼎大名。近年来Erlang在互联网应用中的流行也跟ProcessOne的杀手级应用ejabberd有着密切的联系——Facebook的IM服务器采用的就是定制版的ejabberd。ProcessOne还有其他的一些有趣的项目，比如：

    * CEAN
          o Erlang应用管理工具，借鉴自CPAN
    * Talkr.im
          o ProcessOne的IM服务，支持AIM、ICQ、MSN/WLM、Yahoo!等多种IM协议网关，近期还推出了Google Wave的协议网关
    * Tweet.im
          o Twitter/XMPP网关，借助Gtalk或任意一款XMPP客户端即可免翻墙轻松访问Twitter（最大的缺点是不支持RT）

OTR

如果觉得ProcessOne还是不足以受信怎么办？好吧您可真够多疑的。这时候就可以祭出OTR了。OTR实际上是一类技术的通称，全名是Off The Record，用以指代避免在服务器上以任何形式留存下消息明文的各种技术。

OTR的基本原理其实也很简单，简而言之就是借助公钥加密算法多做一层加密。以XMPP为例，拆解一下就是：

   1. 参与IM通讯的每个IM用户都自行生成一对公私钥对，并将自己的公钥发送给对方
   2. 若消息发送方打算发送消息M0，则发送方首先用接收方的公钥和自己的私钥对M0进行加密、签名，得到M1
   3. M1被投递给XMPP客户端程序，客户端将使用TLS对其进行二次加密，得到M2
   4. M2经由服务器被发送给消息接收方的XMPP客户端程序
   5. 消息接收方客户端程序收到M2后通过TLS解密还原出M1
   6. 接收方用自己的私钥和发送方的公钥对M1进行解密、签名校验，最终还原出M0

这样做的好处在于：

   1. 由于公钥加密的介入，无论所使用的底层IM协议是否支持加密，消息本身的保密性都可得到保障
   2. 即使IM服务器尝试对消息M2进行解密，也只能还原出M1，而无法得到M0；也就是说服务器端无论如何都得不到消息明文

这样一来，即使服务器端尝试对解密出的消息"明文"进行存储，也只能存储由公钥加密保护的M1，而无法触及M0，OTR也正是由此而得名的。
Pidgin Encryption

Pidgin便有一个OTR插件——Pidgin Encryption，可对Pidgin支持的各种IM协议进行OTR保护。Debian/Ubuntu用户可以直接从aptitude安装pidgin-ecnryption包。

使用PE时，需要消息收发双方都安装该插件，并各自生成自己的密钥对（推荐使用4096位密钥）。发起会话时，PE会自动发起密钥交换过程，用户只需确认对方的公钥即可。后续的会话过程便都将处于OTR的保护之下。

使用OTR虽然非常安全，但使用起来也相应地有些麻烦。比如通讯双方必须使用相同的OTR算法（这往往意味着双方必须使用同一种IM客户端及OTR插件），以及必须小心保护和备份密钥对文件以防被盗取或遗失。
XMPP/OpenPGP双剑合璧

如果各个客户端都采用标准的IM协议和OTR算法，那么不同客户端之间的互操作性就可以大大加强。我们已经知道XMPP是一个标准、开放的IM协议，同时也知道了OpenPGP是一个基于公钥加密算法的隐私数据保护标准。那么是否能在XMPP上采用OpenPGP作为OTR算法呢？

事实上XMPP的扩展协议之一，XEP-0027便定义了在XMPP中使用OpenPGP的方法。Psi已支持XEP-0027，Pidgin则尚不支持。不过我在这里发现确实有人在进行Pidgin的GnuPG插件开发。
结语

墙内的网络环境越来越恶劣，让人越来越没有安全感。但其实要对个人隐私进行一些基本的保护，也并不困难。当然不希望在日常生活中也不得不用上这些方法，这篇权且当作是未雨绸缪。