国色天香，不单指青春的靓丽和动人的容颜，更有那丰富的雅韵、秀美的气度和温柔的情怀，还有那随着岁月的流水而日趋丰盈的学识、见地、智慧与灵魂。唯有这样的美丽，方可历久弥新，气韵芳华。
恭祝各位女性宾朋节日快乐！
Unread items (1)
冯培的BLOG
Recent items
冯培的BLOG
delphij's Chaos
-
FAST 2010第二天
Posted: February 26, 2010, 1:14pm CST by Xin LI
Tags: Development
今天的话题都是我比较感兴趣的。
开场的Keynote是eBay的Oliver Ratzesberger的 Enterprise Analytics on Demand。eBay每天的数据增量是50TB，而每天的数据处理量是50PB。这个presentation讲了相当多的规划方面的细节。
第一篇 DFS: A File System for Virtualized Flash Storage 介绍的是一个把卷管理（并不完全是：包含了Flash的wear leveling）和文件系统集成在一起的设计。FusionIO公司提供了一种直接在PCIe接口上插的存储设备。类似这样的设计，感觉是未来Flash文件系统必须要走的一条路。
第二篇 Extending SSD Lifetimes with Disk-Based Write Caches 是一个很有意思的设计：现时磁盘的反复擦写寿命要远好于Flash，因此，在磁盘上做一个顺序写入的日志，然后再择机将数据擦写回Flash。不过这篇论文讨论的具体方案还有一定的改进余地。
第三篇 Write Endurance in Flash Drives: Measurements and Analysis 是关于 Flash 寿命的衡量方法。
下午的session主要是并行计算相关的内容。 Accelerating Parallel Analysis of Scientific Simulation Data via Zazen 介绍的是一种用于科学计算的文件系统，性能不错。
第二篇， Panache: A Parallel File System Cache for Global File Access 讨论的是分布式文件系统中的 cache 问题。准备找时间做做测试。
傍晚的session是关于监控和自动化负载均衡的，现时做起来暂时还缺少机会。
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=b4bc834f-28c6-4717-b989-dc1f1c15523b)
-
FAST 2010第一天
Posted: February 25, 2010, 3:00pm CST by Xin LI
Tags: Development
今天去参加了在San Jose举行的 FAST '10 第一天的 Tech Session，FAST是 USENIX 主办的关于文件和存储技术的学术会议。记上几笔。
开场的Keynote其实讲的还算精彩，不过感觉跟会议本身关系不大（讲的主要是发展中国家的手机等设备的发展），就不介绍了。
Build a Better File System and the World Will Beat a Path to Your Door部分。第一个是本次的获奖论文 quFiles: The Right File at the Right Time ，具体来说是实现了同一份data（文件）的不同view（例如，将其表现成不同分辨率、码流等）的一种通用的存取方法。个人对Semantic File System持保留态度，不过这个talk还是可以帮助拓宽一下思路。
第二篇是介绍在 WAFL 类型的文件系统（具体举例是 btrfs） 中实现倒排索引的 Tracking Back References in a Write-Anywhere File System。具体来说，是在 inode -> 块这样的单向关系基础上，增加了块->inode（包括inode版本、回收时间等）的倒排索引。paper值得看但是性能比较做的稍微有些瑕疵（用做B-Tree的时间去比较在FS中查询的时间，而没有比较建立倒排索引之后更新与在block中插入信息所引起的开销，以及两者对应的查询时间）。
第三篇指出了内存故障可能导致的问题，指出 ZFS 的 end-to-end 检查只能检测出磁盘介质或控制器偶然故障引起的问题，而系统主存中存在的问题则无法发现并可能导致数据损坏甚至系统崩溃，并提出了在 ext2 FS 中增加运行时checksum检查的方案。这篇的试验方法和结论受到了很多人的质疑。
午饭时间。
下午的Looking for Trouble环节是我比较感兴趣的，这个环节主要是讨论故障检测、预防的方法（很多内容似乎跟 LISa 的话题更符合？）
第一篇 Black-Box Problem Diagnosis in Parallel File Systems 提出了一套通过观察一些运行时的响应特征来检测并评估分布式文件系统中所存在的网络、磁盘问题的方法。这个方法值得借鉴，具体来说是事先收集一组正常的性能数据，并在系统运行的过程中收集这些性能信息并与正常的数据比较。由于不同的客户端、服务器角色都能够收集数据，通过一定的统计模型，可以以很高的概率预测遇到的问题是位于网络、磁盘、客户端还是服务器端。
第二篇 A Clean-Slate Look at Disk Scrubbing 和第三篇 Understanding Latent Sector Errors and How to Protect Against Them 主要是讨论在 RAID 和单片盘使用过程中，以主动巡检 (scrub) 的方式去事先检测故障的方法，不过两篇有一些相反的结论（第三篇有来自NetApp的数据支持）。一些我认为比较重要的发现（如果两篇结论相反的话，我采用的是第三篇的结论）：磁盘上的故障点倾向于集中出现，巡检时，遇到坏块可考虑首次扫描中立即跳过128MB；磁盘品质在前2个月的时间会比较稳定，因此在两个月之后应考虑增加巡检的频率，而前两个月做scrub则不需很频繁；数据并未显示巡检（或读写）操作本身会显著降低磁盘的使用年限；发生2处错误时，有90%的情况是发生在两个盘上；staggered scrubbing（以采样的方式将磁盘分成若干大块，并只抽取大块中的一小部分做scrub，见第二篇）可以将检测到故障的时间缩短40%，等等。
傍晚的时候是WiP部分。比较感兴趣的是 Non-Volatile Transactional Memory、The Hot Pages Associative Translation Layer for Solid State Drives（SSD存储结构的改进）和Revisiting I/O Middleware for the Cloud；The Case for a New Sequential Prefetching Technique这个话题因为没有看到具体的算法，所以暂时还不知道效果如何，期待下次FAST能看到。
冯培的BLOG
delphij's Chaos
-
车棚该漆什么颜色？
Posted: February 22, 2010, 7:04am CST by Xin LI
Tags: Others
很多争论其实是源于沟通和理解。人们的理解能力往往是有限的，这些限制很可能来自于不同的教育背景、知识面等等，因此，为了更好地理解对方，人们往往习惯于使用 自己熟悉的 知识去设法理解对方所说的。
这带来的一个现象，在技术人员之间的讨论中，就会是这样：例如，讨论应该怎么造一枚火箭，往往不会有人去随便做评论，因为他们很清楚自己并不是这个专业的人，而这件事明显需要许多非常专业的知识；而如果讨论火箭发射基地的车棚应该漆成什么颜色，则几乎每一个人都会去发表自己的意见，因为车棚的颜色是什么样子，在多数人看来往往没有造火箭那么重要，并且，似乎每个人都能够胜任这样的决策。
将讨论如何造火箭的话题，阴差阳错地变成一群人争论火箭发射场外面的车棚应该漆成什么颜色，就是我们所说的 Bikeshed 现象。
我在这一天时间里遇到了两次这种问题。第一次是我自己把冯牛说的税的算法问题想错了，第二次是我的关于什么时候该用线程的问题被另一个人活活 扯成了 线程 vs 进程的开销问题。
解决 bikeshed 是需要时间的。不过，每一个参与讨论的人，其实都可以尝试使用一些方法来减少这种情况的发生。例如：
头脑空白原则：如果对方讨论的是一个你认为自己很熟悉的话题，不要首先根据自己的理解去下结论，而要先看清楚对方到底在说什么。许多时候，我们自己的知识背景会限制我们能够看到的问题的范围，很可能对方想要讨论的并不是这些东西。
在发现争论持续了很长时间，双方各执己见时，暂时停止讨论，而不是继续论证自己的观点。一个观点的对错取决于观点本身，而不是争论双方所说的话。
避免情绪化的语言----那不会增加你的说法的说服力。
冯培的BLOG
Rainbow
-
三亚 2009.11
Posted: February 17, 2010, 5:43pm CST
三亚 2009.11
Still On My Way
-
想起来很美
Posted: February 17, 2010, 3:31pm CST
div想你时你在天边，/div div想你时你在眼前，/div div想你时你在脑海，/div div想你时你在心田。/div div一直喜欢李健的这首歌，不过王菲唱之前，我一直不知这首歌的名字就叫《传奇》/div p /p p日子一天天悄悄溜走，虎年的春节眨眼过去了。日子很宁静，平静，觉得很真实。/p p没有搜肠刮肚堆砌新年祝福的冲动，也没有等待别人新年贺岁的期待。/p div去到一个通信不太通畅的地方过节，安静的很，连找一个放鞭炮的地方都比较费劲（我们在大马路上放的炮）。/div div没有令人腻味的大鱼大肉，最尽兴、过瘾的事情，就是挖掘主人家能吃的东西，变成美食，大家一扫而空。/div div赫赫，我还是很喜欢下厨的。/div div居然在走路60分钟来回的距离内有一个大的农贸市场，居然卖菜的小姑娘有很新鲜的蔬菜，居然买了一大堆才花了30元。/div div卖水果的摊主很不开心，因为她的水果在大年初一的夜里被偷走了很多，损失上千元。安慰她也不管用，索性买了200元的水果，串门自己吃都很不错。/div div /div div在外住了几天，心情难得地好，晚上睡眠也好，一觉睡到天亮。/div div /div div今天要值班，不得不在昨天打道回府。刚背包出来等公交车，就接到一堆的短信还有电话。/div div晚上回家，满脑子就又都开始工作啦、小升初、电脑病毒、同学朋友聚会，一通地电话短信....../div div /div div今年的寒假，基本上所有的时间和精力都在教子，不惜沦落到三陪（陪吃、陪住、陪学），心情感觉还不错。/div div出门在外几天，才觉得卸掉工作压力还不是最好的，还要卸掉孩子的压力，才可能真正轻松！/div div盼望着、盼望着，东风来了，春天的脚步近了！说着，就到“解放”的日子啦！/div div /div div遗憾哦！很想去趟圆明园的庙会，可惜没时间去啦！就想想吧！/div div /div div /div
冯培的BLOG
delphij's Chaos
-
安全：该做什么和不该做什么
Posted: February 3, 2010, 9:08am CST by Xin LI
Tags: Security
很多事情都有Do's and Don'ts，这里试着整理一下与安全有关的。
本文版权所有 © 2010 Xin LI <delphij@FreeBSD.org> 保留所有权利；非商业转载请注明出处 [blog.delphij.net] ， 谢绝商业转载。
安全不能建立在"别人不知道"的基础上
"别人不知道"是一种非常常见的安全 假象，举例来说，一种自己设计的山寨加密算法、一个系统中一般人不知道的位置等等，都属于这一类。
将安全建立在"别人不知道"的基础上是非常危险的。首先它会给设计者和用户带来"安全"的幻像，这会直接导致与系统交互的人放松警惕；其次，这样的设计往往留有"后门"，甚至是设计者不知道的后门（因为往往他们并不对这类设计进行充分的、专业的审计），容易被攻击者利用；最后，这种做法存在第三方泄密问题，即，使用这种系统的人，需要提防设计系统的人被其他人买通并泄漏一些秘密的情况。
延缓攻击的手段不能用来阻挡攻击
有许多延缓攻击的手段，例如改变服务的端口（比较常见的如将 ssh 改为 tcp/22 以外的端口），或禁止服务程序显示自己的版本等等，或仅仅简单地启用防火墙，这些手段起到的作用只是延缓攻击，而不应作为一种安全屏障。对于多层次式的安全设计来说，采取这些措施有助于提高检测到入侵的机会，但是它们本身并不会提高安全性。
与前一种情况类似，这种做法也只是让管理员放松警惕。例如以 ssh 为例，有人认为将端口改为一个非知名端口可以避免相关的攻击，但事实是，攻击者依然可以利用 ssh 实现或协议设计中存在的一些漏洞来攻破系统。拥有特定资源的攻击者甚至不需要直接对目标系统实施攻击。在较复杂的攻击手段中，包括简单的 port knocking 一类的保护手法，都可以使用类似分组重放这样的方法来逐步攻破。
采用层次式的安全设计
所谓层次式的安全设计，说的是在一套安全系统中包含不同层次的、存在层次式监控关系的安全结构。例如，将本地包含执行文件的那些文件系统通过一定的方式导出给监控网段的机器，就可以让那些机器在攻击者不知情，或至少不太容易注意到的情况下对入侵进行检测；通过将一些重要日志发到以不同的访问控制机制，甚至不同网络协议的记录设备上，则可以有效地检测入侵者的入侵行为，并为日后的分析留下更多的有用信息。
层次式安全在现实中也有应用。例如产品的质检，除了制造商自己进行的质量控制之外，有时分销商或政府也会进行一些抽样的检查。我们注意到，这些设计中的一个重要的特点是在不同的系统中使用不同的访问控制逻辑。例如，日志服务器必须从特定的客户端，甚至只能从某些隔离的内网登录。此时，延缓攻击的手段可以作为它的一项辅助设施，即其目的并不是阻止攻击，而是吸引攻击者在攻击目标上花费更多的时间，从而帮助入侵检测机制更容易地检测这些攻击。
不要轻信任何东西，包括X.509证书
安全系统的设计者必须对安全有全面的理解和认知。有一句很著名的话叫做 In God we trust, all others must submit an X.509 Certificate，需要注意的是，这里说的是 must submit，并没有说 submit 了就可以 trust 了。
和前面所说的层次式安全设计类似，我们的一个基本假定应该是，一个安全系统中的任何参与者，无论是用户还是计算机或程序，都是可能存在弱点的。安全系统，或用户，都不应轻信任何东西，例如，在特权隔离 (Privilege Separation) 这样一种设计中，特权进程除了完成那个非特权的子进程的请求之外，还有一个任务是维护一个"理性状态机"（Sanity DFA），这个状态机的作用是检测非特权进程的异常状况，如果发生这样的情况，则特权进程有拒绝提供服务，并杀掉非特权进程的责任。作为用户，对于系统给出的响应，除了验证对方的证书之外，也应有常识性的了解和适当的判断。
不要把安全建立在不靠谱的基础设施上
举个现实生活中的例子，修一座桥，结果水泥标号不够；修一座楼，结果钢筋用竹签代替，有可能稳当吗？
然而在安全系统的设计中，很多人却往往忽视这样显而易见的问题。比较典型的就是许多网站所采用的所谓"安全控件"的技术。每一个这样的新设施，都意味着新增的攻击面和一组可能可以利用的新漏洞。
在一个安全系统中，防守的一方一定是弱势群体，因为他们必须按照一定的规矩去设计系统；而攻击者则可以采用最便宜的攻击方式。时刻牢记，在你花费时间去加强系统中最坚固的部分的时候，你的对手则正在靠近这个系统中最薄弱的环节，甚至可能是在你不知道的情况下！
下面是一些典型的不靠谱安全设施：
- 自己设计的算法。（公开的算法经过了更多的专业人士的验证；而自己设计的算法则没有，每个人的知识面都会有些局限，即使第一流的密码学设计者也可能设计出糟糕的算法，因此同行的验证很重要）
- 监控键盘的驱动程序。（这类做法不仅不能对安全产生助益，反而会给其他木马带来监控用户键盘，从而攫取其他机密信息的便利）。
- 基于明文的通讯协议。（当数据需要经过不受控制的网络节点的时候，端对端加密是非常重要的）。
操作复杂不等于安全
一些安全措施在实施了之后，用户可能会发觉与之前相比会带来一些不便。有些不便可能是无法避免的，但这并不意味着，使用的时候给用户带来不适的安全设施就一定会提高安全性。
举例来说，一些银行在登录时，会在用户输入用户名之后，先显示一张用户自己定义的图片，然后再让用户输入密码。这种设施本身并没有改善任何安全性，因为中间人攻击仍然可以获得那个图片，更糟糕的是，由于看到了希望看到的那张图片，用户反而会对这个网站产生安全幻觉。
而另一种做法则是给用户一个小的token，这个token能够根据网站和token之间共享的信息和用户自己的密码来计算出一个登录用的一次性密码。拿到这个一次性密码的攻击者，并没有很好的办法再次使用这个密码来做别的事情。
代码开放和安全是不是一回事
许多人认为，开放源代码的东西更安全一些。这种说法并不完全正确。还有一些人认为，因为代码大家都可以看到，因此开放源代码的东西更安全，事实上，后面这种看法完全是逻辑混乱。
举个例子，面对来要求审计账目的税务局，一个CEO的回答是，我的账目绝对没有问题，因为我这家公司上上下下200多人都可以随时去看。毫不意外地，这个审计师决定自己再看一遍，因为这是一家广告公司，而"能看"和"看过的人都是内行"以及"有多少内行看过"也是完全不同的概念。
在选择一个解决方案的时候，如果一定要参考其他人的意见的时候，一定要看这个意见是来自什么人。开放源代码的产品一样有可能会存在漏洞，看它代码的人很可能并不是很有安全方面知识和经验的人，有这些经验的人可能在看其他的开放源代码，甚至不开放源代码的产品，等等。真正重要的是，找一个值得信任的专业人士去做这样的评估，而不是仅仅看一个和安全与否关系不大的指标就匆忙决定。
使用公开的、经过验证的安全算法和协议
算法和协议是实际应用中的安全系统中最关键的两个部件。经过验证的、公开的算法和协议有这样一些无法替代的好处：
- 设计它们的坏人有足够的专业知识。
- 试图攻击它们，并且也有足够专业知识的坏人已经证明，攻破它们需要的代价大到不值得从这个方面去突破它们。
- 坏人之间为了证明自己做了充分的对抗性的同僚复审。
- 它们被破解的时候，你可能不是最先知道这件事的，但是也不会是最需要担心这件事的人。
- 最重要的一点：设计一个自己破解不了的东西很容易，而设计一个 别人 破解不了的东西很难。我要提醒读者的是，你需要的是别人破解不了你的系统，而不仅仅是你自己破解不了。
避免同一类型的弱点
攻击者在攻击的时候，往往会采用最"便宜"的方法去进行。例如，在发现一个由于程序设计问题而导致的安全漏洞时，除了修正这个问题本身之外，还应对系统中可能存在类似问题的其他环节进行类似的代码审计。对于开源项目来说这一点尤其重要。
例如，如果OS允许在地址0附近映射内存页，则由于欠锁一类原因导致的竞态条件所导致的可能就不仅仅是崩溃了。这类问题的典型用例是先将自己的代码映射到地址0附近，然后设法触发内核的一个可能导致空指针引用的函数指针调用，这样系统将会在内核的上下文运行那些代码（说明：出于性能考虑，一般来说内核并不会切换到一个完全不同的地址空间去运行）。尽管修正竞态条件本身很重要（例如FreeBSD SA 09:13.pipe），但通过禁止在地址0附近映射内存页，可以将这一类型的潜在漏洞全部由特权提升降级为崩溃或死锁，因此也就有了 FreeBSD EN 09:05.null 所做的改动。
避免过度设计，优先改进最薄弱的环节
过度设计是许多工程师会遇到的问题。例如，在内网交换机上传输加密数据，在多数情况下都是不必要的（听不到发到其他节点的包，而听包本身所需要的权限已经足够做其他事情）。
攻击者不需要遵循任何规则，而防守者则必须遵守一定的标准。因此，作为原则，防守的一方应假定攻击者会找到系统中最薄弱的环节，或者说，站在攻击者的角度去思考从什么地方去攻陷系统，并加强系统中最薄弱的那些环节。
不过，想要避免这些设计问题，必须拥有许多相关的知识和经验。
今天先写到这里，改天继续总结。
冯培的BLOG
-
年度网络流行语——什么在流行（3）
Posted: February 2, 2010, 5:58pm CST
戏谑与无厘头，以及其极端的形式——恶搞，大约以胡戈的《一个馒头的血案》为开端，一直是数年来网络中流行不衰的主题。2009年的网络流行语中，此风依然尽吹。只是和以往不同的是，以反身代词“哥”为词干的自我戏谑的色彩更加凸显。如一石激起千层浪的“哥吃的不是面，是寂寞”、起源于“猫扑大杂烩”的“不要迷恋哥，哥只是个传说”、本与李宇春毫无关系，却由“快乐女生”的争议人物曾轶可的“曾哥真爷们”推衍派生的“信春哥，不挂科”等。而特别值得推崇的，则是与10年前网络新生代通过拼音输入法的重码而创造“斑竹”一词相近，但更具内涵的“杯具（悲剧）”、“洗具（喜剧）”、“餐具（惨剧）”、“茶具（差距）”等各式摆在2009人生这张茶几上的“牙具（哑剧）”。
其实，戏谑与无厘头在2009年，也是欧洲大众传播的某种流行。法国总统萨科奇夫妇被美国动画片《一丝不挂的恶魔》尽情嘲讽；意大利总理贝卢斯科尼因不断的绯闻颇像一名摇滚巨星而被世界知名摇滚乐杂志《滚石》评为2009“年度摇滚明星”和封面人物；德国总理默克尔也饱满的身材而在德国狂欢节上被设计成“裸体小姐”形象。如果说这些政客还是属于“被戏谑”的话，那么岁月交替之际在电视台上呈现的俄罗斯总统与总理向人们祝贺新年的两个卡通形象，则是一种通过自我戏谑而亲民的主动行为。
有学者言，一代人创造的娱乐文化是自己的“洗具”，另一代人眼里的“杯具”。文化本身就是一个“牙杯”接力棒，在悲喜转换间沉淀升华。所以说，作为年度流行语中溢出的第三个流行，尽管戏谑与无厘头对人们常态认知的颠覆和解构，以及其更多呈现的灰色调，并不能真实准确地映射现实世界的主流，但它为寂寞所提供的一种欢娱，对无奈所释放的一种解压，却从另一个视角和层面，真实准确地代表了人们在思维世界中的群体倾向性。恰恰是这种潜在的东西，才最值得关注。
牛去虎来，新的一年必将又有新的流行语问世。那就让我们静候和关注：又有什么在流行？
delphij's Chaos
冯培的BLOG
-
年度网络流行语——什么在流行（2）
Posted: January 29, 2010, 10:52am CST
去年的这个时候—— 2009年1月30日，24岁的李荞明在云南看守所内因与同室狱友玩被公安机关称之为“躲猫猫”的游戏而离奇死亡。当社会广泛质疑和呼唤“谁来看守‘看守所’”之时，“躲猫猫”一词也迅速成为进入2009年的第一个流行语。与此相似的，还有杭州飙车案的“70码”、上海闵行的“钓鱼执法”、浙江湖州的“临时性强奸”等这些事件本身并不复杂，但初始结论却匪夷所思，从而引起网民广为关注和热议的滑稽词汇。
与往年流行语相比，类似“躲猫猫”这样叠词架构词语的重复出现，同样构成了与前述“一句式模仿”一样的流行。如随上海闵行新楼像被“鲁智深倒拔垂杨柳”一般整体匍匐而爆出的一系列危楼事件的“楼歪歪”、“楼脆脆”、“楼垮垮”所形成的“楼XX”，以及各式各样“被就业”、“被代表”、“被小康”的“被XX”。尽管如同本年度的一句流行语所说，“这个事我不好再说太细”。但公众对各种频发的公共危机事件在第一时间获得的解释和回应所表达的迷惑和无奈，却是显而易见的。
一个事业的成功，需要千人万众；一个组织的形象的形成，需要千言万语。可毁掉一个事业，也许一个人就够了；败坏一个形象，一句话足矣。虽说今天的网络及其流行语的传播，在虚拟世界构成了洪流涛涛的人声鼎沸，可现实世界中，究竟真实的民意谁在倾听？正因此，这类流行语的流行，更多的只是民众无奈的一种宣泄。
由此看来，无奈，是流行语中溢出的第二个流行。
delphij's Chaos
-
纪念消失的Sun
Posted: January 29, 2010, 8:13am CST by Xin LI
Tags: Others
欧盟日前正式无条件批准了Oracle收购Sun的交易，至此，有着28年历史（1982 - 2010）的Sun公司作为独立公司的历史正式宣告终结，今天，Sun的网站已经变成了301 [www.oracle.com]
"For 28 years, Sun has stood for courage, innovation, a willingness to blaze trails, to envision and engineer the future."
-
用户口令的验证问题
Posted: January 29, 2010, 6:29am CST by Xin LI
Tags: Security
口令是许多系统中用于判断用户身份的重要手段。当然，使用口令作为身份验证方法是很不靠谱的（例如，许多用户会使用弱口令，或者在多个系统中使用同样的口令，以及它存在对称失密问题，等等），不过因为口令便于携带（相对于私钥）和实现，因此仍然被广泛使用。
验证用户口令有很多种不同的方法。最原始的方法，就是将用户输入的口令与我们保存的口令相比较，如果相同，就认为是验证通过。但是这样一来，我们就必须保存用户的口令，而保存用户的口令会导致很多问题，例如，假如系统用于保存口令的数据库被攻陷，直接泄露用户的明文口令肯定不是一件好事。
于是，我们可以对前面的方法进行改进，即，只保存用户口令的散列（hash）字符串，而不是口令的明文。散列算法是一种单向的计算，即散列函数 H 对明文信息 p 计算出的结果 h：
H(p) = h
从 p 根据 H 推算出 h 需要的计算工作很容易完成，而通过 h 则很难推出 p（一般来说，散列算法生成的输出结果是固定长度的，因此这个过程几乎一定会导致熵的减少，从而使 h 中包含的信息少于 p）。安全的散列算法还需要提供一些其他的特性，例如"雪崩效应（Avalanche effect）"，即明文信息p中哪怕仅仅改变1个bit，也会导致输出的h中多个bit的变化；输出的散列值均匀分布，等等。目前比较常用的安全散列算法是SHA2。
不过，仅仅使用散列算法来处理字符串并不能解决所有的问题。随着计算技术，特别是分布式计算和存储技术的不断发展，使得产生某种散列算法每一种散列输出，并保存一个可能的、与之对应的输入变得越来越容易。例如，SHA256 ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad对应的一个可能的字符串是abc，如果我们只保存密码的hash数据的话，攻击者遇到ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad时，无论用户真正的密码为何，便总可以使用等效字符串"abc"来进入系统。
挫败这种攻击的方法是使用一个额外的随机串，并且在保存密码时，每次都生成一个新的随机串，将其以明文方式和散列串放在一起。例如，在保存密码时随机生成的随机串是hFaSV2，我们便把它和用户的密码abc连在一起去计算散列值，即，SHA256 ("hFaSV2abc") = 31945b4ad715f72214a8c84a3b63aa5aecf3ba9419a7687d90351da4d525d1fa，保存的时候可以写成$hFaSV$31945b4ad715f72214a8c84a3b63aa5aecf3ba9419a7687d90351da4d525d1fa$，这样在用户再次输入密码时，便可以配合这个串来进行验证。由于我们的随机串对每一个用户而言都不一样，攻击者就没有办法通过查找事先计算的字典来得到等价的字符串了。
然而，近几年的密码学研究成果还增加了另外一种形式的攻击，即，某些算法在有一部分已知明文的时候，可以以较低的代价推算出能够得到等价散列串的其他字符串。因此，前面的方法还需要进行进一步的改进。除了使用更好的散列算法之外，还可以通过多次散列得到的反馈来提高推算等价串的代价，也就是说，原先的系统中，我们计算的是：
H'(s, p) = H(s + p) = h
而改进的系统中，我们计算的则是：
H''(s, p) = H(H(s + p) + s+p) = h
上面的方法可以做多轮以加强效果，这里，我们将散列得到的信息以一定的方式反馈到散列函数的输入中。这样做的结果是，攻击者虽然了解我们生成的随机串 s，以及最后的结果p，但却没有很好的办法去推算我们在计算过程中使用的中间结果H(s+p)。这种做法可以挫败一整类这样的攻击。
在 *BSD 和 Linux 中的密码文件里所使用的 MD5 就是采用这样的方法，其实现中将散列串的输出结果以及原字符串不断地以输入的形式反馈到散列函数中，从而达到提高攻击门槛的目的。
-
端到端(End to End)加密与安全
Posted: January 26, 2010, 6:34pm CST by Xin LI
Tags: Security
说明：这篇文章希望能够以比较通俗的方式介绍一下相关的概念。
端到端加密，通常是指两个通信实体之间在会话通道基础上进行的、由两个实体之间协商的密文会话。端到端加密的好处是能够减少会话通道本身的泄密或其他问题导致两个通信实体之间的通讯遭到第三方破译，并避免通讯的对方对通讯内容抵赖（即，不承认通讯内容来自自己）。相对而言，端到端加密的实施成本要比单独架设一条物理的通讯线路要便宜许多，因此有时它也用于架设这类通讯线路。端到端加密本身不能阻止由于使用的会话通道本身的丢包导致的干扰。然而，由于端到端加密可以工作在较高的抽象层次上，它可以使用多个实际的会话通道而提高抗干扰能力。
通常我们会希望在一个安全系统中设置多个层次的安全设施，或者说类似"洋葱"的模型，例如，在系统中，将所有与安全有关的信息记录日志并放到不可擦除的介质上、对连接进行加密，和对发送的消息进行加密，这几种方法分别考虑的是不同级别的信息安全，而这些方法可以在同一个安全系统中作为其不同的保护层次来使用。在这一类模型中，我们不仅视阻止入侵为目标，同时也将检测入侵做为目标，或者换言之，每攻破系统中的一个层次，入侵者都需要付出额外的努力，并冒更大的被发现的风险才能达到这样的目标。
以邮件系统为例，传统的电子邮件系统是完全不使用任何加密或签名的手段的。拥有接入层控制权的网络管理员，可以轻易地通过在网络上监听数据包来获知用户与自己所使用的邮件服务器之间交换的邮件内容。随后，当邮件到达了邮件服务器时，邮件服务器管理员也可以很容易地知道邮件内容；在邮件服务器将邮件传送到互联网上的另一台邮件服务器时，问题就更多了，每一跳路由，以及它们所经过的所有网络都可以被监听，并将邮件内容泄漏出去；最后，在另一台服务器和收件人之间，也有和发件人这一边一样的风险。
在Internet上传输电子邮件的过程，由于其经过的环节众多，并且几乎完全不受收发邮件的双方控制，因此很容易导致一些敏感信息的泄露。针对这种问题，人们设计出了一种叫做Transport Layer Security（TLS，用于替代SSL）的密码学协议来实现服务器之间，以及客户端到服务器的端到端安全。简而言之，这套协议首先使用公钥加密算法在通讯双方之间协商一个会话密钥，并用这个密钥完成之后的通讯加密/解密。公钥加密算法是一种加密和解密时使用不同密钥的加密算法，以对方公开密钥加密的数据，只能以（不公开的）解密密钥解密，而从公开密钥或已知明文、密文推算出解密密钥的代价非常大，因此它能够确保数据只能被"正确的"那个接收方解密。
这种密码学协议的实现包括两件事：发起会话的一端需要生成一个随机的"会话密钥"，并以安全的方式（通过公钥加密）发给对方，而双方在稍后的通讯中，则以这个协商好的密钥进行对称加密（加密、解密使用同一个密钥，这种方法性能较好）对会话信息进行加密和揭秘。这样做除了性能方面的考虑之外，还有一个很 重要的是因为发起会话的这一方很可能没有自己的密钥对（公钥+私钥），由于对方的公钥公开，对方使用私钥对数据进行的处理只能看作是"签名"（可以使用公钥来进行验证）而不能作为传回数据时加密之用。这样，在建立加密会话时，接受会话请求的那一方很可能无法知道发起会话的那一方的身份（TLS事实上支持以包含公钥的证书的方式来验证身份，然而由于部署比较困难的原因，这一方法并没有得到非常广泛的使用，而只应用于一些强调安全而非易用性的场合）。
实施了TLS之后（由于兼容方面的考虑，通讯双方都需要启用TLS，否则邮件系统仍会以不加密的方式传输邮件），邮件系统在网络这个层次就无法被截获了。然而，这样做并不能阻止服务器端的管理员查看邮件的内容。我们注意到，在收发邮件时，实际上是两个人（当然，如果深究的话，事实上是代理他们的本地桌面终端）之间的端到端通讯，因此，在这里还应再进行一次端到端加密，使用PGP或S/MIME。这两种方法和前面所说的方法类似，但通讯双方均持有公钥/私钥对，使用自己的私钥来进行签名和解密，而对方的公钥则用于加密和验证对方签名，但在信任方式上则存在不同。S/MIME的信任关系依赖于各级发证机构（CA）所签署的身份证明，而PGP的信任关系则依赖于不同的个人之间对对方公钥进行的签名。S/MIME比较适合在企业内部迅速建立一套验证体系，而PGP则比较接近社会的关系，例如某甲是一个非常值得信赖的人，某乙、某丙虽然有时候满嘴跑龙套，但是还算靠谱，某丁则只有自己说话时候可以算数，说别人的事情的时候全是八卦，在PGP里面可以比较容易地对这些状态予以表达，并据此算出是否应信任某个签名。
说到这里，我们还必须强调一下端到端加密的缺点。首先，端到端加密只能提高通讯内容的保密性，它不能阻止通讯被彻底中断；然后是，端到端加密时，通讯双方的地址必须是公开的。这就好比通过快递公司去发运一个上了锁的保险柜一样，快递公司也许没有办法打开保险柜，但是保险柜本身并不能保证快递公司一定会把它送到目的地，而且，快递公司也必须知道发货人和收货人是谁，才能完成这趟物流。对于有更高保密需求的应用环境，还必须与其他层次的端到端加密结合，才能够达到所希望的效果。
冯培的BLOG
-
年度网络流行语——什么在流行（1）
Posted: January 25, 2010, 5:25pm CST
普希金曾说：“一切都会过去，而过去了的会成为美好的回忆”。当金牛扬蹄而去、银虎呼啸而来之际，2009年的十大网络流行语也原汁出炉，它勾起人们对那些渐行渐远事态的又一番回味。作为社会反光镜和时代透视机的网络流行语，到底折射出什么？究竟什么在流行？
谁也不会料到，7月百度魔兽吧里一个只有标题的空贴——“贾君鹏，你妈妈喊你回家吃饭！”会成为网络世界第一神帖。这不光让传媒的策划者净赚了6位数，也猛然间掀起了一场网络的集体狂欢。19天点击1000万，跟帖30万。由此在60年大庆时演绎的“台湾，你妈妈喊你回家吃饭！”更赢得了广泛的认同。
儿时的我们，都曾有过和两小无猜的玩伴在街头巷尾尽兴淘气、忘却时间的经历。每当开饭之时，或是从身边走过的邻居、或是从幽幽小巷的深处传出的这句再平常不过的话语，之所以让今天的人们再度感受到儿时的温馨与欢快，正说明在终日嘈杂忙碌的当下，人们已经很难经常感受到曾经的那种放松和洒脱。或许我们认识的人越来越多，可心中的朋友却越来越少。网络是虚拟的，现实是虚伪的，每个人在渴望相互温暖的同时，又深度担心自己会被灼伤或被冻伤。于是，面对终日游荡、无所皈依的孤独的灵魂，“妈妈”、“回家吃饭”这些温情的语汇，就成为发自每人内心的一种企盼和呼唤。
与这句流行语相对应，流行语“哥吃的不是面，是寂寞”所缔造的“寂寞党”，以及由此构成的新流行——一句式模仿，都从另一个角度，进一步表明了现代人在生活工作的重压之下，心灵的家园是多么渴望抚慰和滋润。
由此说来，寂寞，是流行语中的流行之一。
-
世博会百日倒计时
Posted: January 21, 2010, 10:13pm CST
-
三九之九话寒冷
Posted: January 17, 2010, 10:10pm CST
今天是三九之九。三九隆冬，滴水成柱，呼气成霜。放眼北半球，朔风千里，银裹万野，江河冰封，满目肃杀。“寒冷”成了每日人们的切肤感受和天气预报的高频词汇。
寒冷，固然是自然温度的客观显示，但它同样也是心理温度的主观体验。外在结冰不过是风物年华的轮回。冰棱再大，太阳一出，终也会化成汤汤水水。可如果心理结冰，不消说融化它尚需整个春天，即便是日日暖阳，也依然会不寒而栗。
外在的寒冷是天为的，心理的寒冷则大多是人造或自选的。正因此，抵御它的办法，就是始终让心灵充满暖阳。
