Shell's Home

Aug 20, 2018 - 1 minute read - Comments

恒春潜水记录

地点在恒春的后壁湖,岸潜4次,船潜12次。岸潜地点在核电站出水口左侧右侧和软珊瑚区域(潜点就叫这个名字,俗吧)。深度都不怎么深,但是越过一堆礁石比较困难。有鞋子保护好歹脚不痛,但是这双鞋子防滑性能一般,我差点在岸边溜冰。 船潜地点在外侧的几个礁石,深度都比较大。独立礁(瞧瞧这名字起的)悬崖部分深度超过30。我有几支用了EAN32,下不了32米的深度。至于其他人,他们基本都没有DD的证,本来就不能下去。 在垦丁附近潜水,最大的风险来自于低温和大流。我本来还和潜导说我就水母衣下吧,反正水温都在29-30左右。潜导说你碰到斜温层就知道厉害。垦丁这里有很多斜温层,底层温度会骤降5度左右,我记录的最低温度是22度,3mm的湿衣冻成狗。比我在PG外岛碰到的斜温层强大的多。最大的流在3节左右。负浮力下水后还没动作抓绳,先被大流压到了梯子上。比我在泰国碰到的流还猛。比较值得欣慰的是,基本都是横流,很少有垂直流或洗衣机。不过同时也有个坏消息。垦丁这边有很多的浮潜,水上摩托和香蕉船。这几个活动的危险性就先不去说了,水上船只频繁运动的情况下,是很容易撞到的——尤其是没有SMB的情况下。 垦丁的能见度不高,一般只有5-10左右。但有趣的是,在斜温层下方,能见度反而更好。往往有10米以上。肉眼可见的原因是因为斜温层的温度有利于浮游生物的生长。不过这也造成一个问题。在垦丁水下拍照,是一定要补光的。因为上方自然光都被表层海水吸收了,底层虽然能见度不错,但光线不足。 物种多样性来说,还不错,经常能看到蓝点鳐,厚唇石鲈。我还看到了龙虾,海蛇和海龟。有看到一只豆丁海马,不知道照没照清楚。出水口左侧的软珊瑚区里,有一堆海胆正在搬家。在核电出水口附近,照道理说,水温会比较高,可能引起珊瑚白化。但实际上珊瑚还不错,偶尔见到白化。 上次在垦丁浮潜,有严重的水下垃圾问题。这次无论是船潜还是岸潜都没有看到特别严重的垃圾问题。有见过几张纸,一次见到塑料袋。比起其他国家来说没有明显糟糕。后来我考虑了一下,水下垃圾估计是因为沉没在水下的部分无法在净滩中清理。浮潜和深潜业者当然有动力去清理他们看到的垃圾(毕竟关系到他们的饭碗),但是这并不能覆盖全部海滩。因此这次我的活动范围可能被清理过,而上次的活动范围则是问题比较大的部分。 在潜水间隔和船长聊过,他们其实是渔船,属于娱乐渔业。每次出海的时候,是要有海政属的人来点人头的。这也间接造成了船的大小很大,每次出海成本很高。我这次是一条船出海一次潜两支,1000NTD。上面往往就三五个人,很多时候教练都比客人多。其他国家经常是一条小船就出去,船上也是三五个人。这样的成本差异接近数倍。 最后说说交通和生活基础设施。恒春没有通铁路,只能通过垦丁快线(巴士)来返。从恒春到左营大约是两小时左右。但是去的时候最近一班车没票,回的时候正常车都没票,最后在等加班车。可见总体运力并不是很足。住宿方面,恒春老城里有很多民宿,可选择空间很大。我很喜欢乡村鸭肉冬粉家的卤味(不是他家冬粉),和对面的洋葱冰淇淋(是的,洋葱冰激凌,恒春产洋葱)。基本来说,你可以认为,这里除了可以讲中文外,基本和你去的其他潜点没什么区别(主力语言还不是普通话,而是闽南语,大部分人聊天的时候,我感觉和东南亚没啥区别)。

Jun 14, 2018 - 13 minute read - Comments

递归有关的几个小问题

引子 在加密系列里突然出这么一个问题,确实有点怪。我犹豫了一下,还是先写了再说。 这个问题的提起,是公司老大kay提出一个问题。在反转链表的时候,如果有环怎么办。然后我们就现场写各种解环算法。这个问题本身不难,我们先看一下原始问题和解,还有带环反转。 Scheme反转链表 想了想,还是先写Scheme版本。这个版本实现简单概念清晰,个人觉得非常典型。而且对后面理解Python版本很有帮助。如果看不懂的话,可以直接去看Python版本。Python版本看不懂了再回本章来,去看Scheme入门教材。 Scheme的正解版本只有一个,就是带复制TCO版本。 (define (reverse-tco ll rslt) (if (eq? ll '()) rslt (reverse-tco (cdr ll) (cons (car ll) rslt)))) 这个版本体现了Scheme的几个特点。 递归比迭代好使。 强制要求TCO。 cons操作起来非常方便。 Python递归反转链表 def reverse_tco(ll, rslt): if not ll: return rslt return reverse_tco(ll[1], [ll[0], rslt]) 这是链表最简单的问题,也是递归论最基本的问题。注意这里采用list来模拟了lisp中的cons,不用tuple主要是后面还有环,需要修改数据。如果你不明白,可以先看Scheme版本的代码。 递归转迭代 写到这个水平,其实有一半的被面人就挂了(好水)。但是这个水平其实也就是入门水平。最低限度,也要知道上面这个递归是可转写为迭代的。更进一步的,要知道这个递归是个尾递归。下面我们把这个代码转写为迭代形态。 def reverse_iterate(ll): rslt = None while ll: rslt, ll = [ll[0], rslt], ll[1] return rslt 或者非生成节点版本。 def reverse_iterate(ll): rslt = None while ll: rslt, ll[1], ll = ll, rslt, ll[1] return rslt 这里的区别,其实是SICP第24页所说的“递归计算过程”和“递归过程”的区别。具体请直接参考原书,我就不打字摘抄了。

May 12, 2018 - 3 minute read - Comments

openssl证书相关

鸣谢和前言 首先感谢Ivan Ristić。本篇很多内容可以从他的这本书里读到。大家如果有钱,可以买来支持一下。没钱但是英文好的话,也可以直接读一下(这本书在网上是公开的)。本文没有直接复制,引用,或是完全写成读书笔记。所以原则上是不受书的版权限制的。不过如果作者有异议的话,我愿意下线这篇文章。 First of all, I wanna say thank you to Ivan Ristić. I got a lot of help from this book. You can buy one if you want, or read it personally (it’s public). This is really a good book. In this article (I mean the one you are reading currently), I don’t copy or reference directly from that book. So as far as I know, it shouldn’t have any copyright problem.

Apr 1, 2018 - 2 minute read - Comments

openssl基本密码学操作

openssl的基本检查 使用以下命令检测版本,-a可以提供完整数据。 openssl version openssl version -a speed test speed测试是openssl为你跑一下不同算法在你机器上的实际执行速度,这项测试在openssl中是一项非常有指导意义的测试。一方面,他给出了你选择算法的依据,通过实际数据告诉你每个算法能跑多快。另一方面,他可以用来评估不同硬件对算法的加速能力。如果仅仅是给出了选择算法的能力,我们一般都可以得到一个一般性结论,例如chacha20比AES快。但实际上很多CPU带有AESNI指令集,这种情况下AES的执行速度反而会更高。所以运行性能是和执行平台紧密相关的。关于这部分,可以参考Intel对OpenSSL的性能优化。 具体的测试方法是 openssl speed 后面可以跟算法,只测试特定的算法集。 我这里跑了一遍全集,挑几个重点算法说一下性能吧。 hash算法 sha256,标杆性hash算法,64字节小数据140M/s,8k大数据353M/s。sha512,170/470。hash算法的内部状态越长,在连续计算时的速度越快。 sha1,251/768。 md5,243/575。(你没看错,md5比sha1还慢) rmd160比sha256还慢,whirlpool比sha256慢。最快的是ghash,小数据4222/9732。但是见鬼的是,我查不着这是TMD什么算法(openssl list -digest-algorithms的输出里没有)。 最合适的算法,应该就是sha-512/256了吧。很安全,速度比sha256快,长度也不算太长,还能防御LEA(Length extension attack)。 对称算法 aes-128-cbc,标杆算法,120/125(M/s)。aes-192,93/103。aes-256,86/88。aes的内部状态越长,在连续计算时的速度越慢。这点和hash正好相反。 camellia128,138/167。camellia192,110/128。camellia256,109/124。这是一种大批量数据计算非常优越的算法,AES在计算大批量时性能上升并不快。 des比aes慢的多,只有66M/s。3DES更慢,只有25M/s。 没有chacha20。 不考虑chacha20的情况下,最好的算法应该是camellia128。当然,工业标杆是aes-128-cbc。 非对称算法 rsa 1024/2048/3072/4096的sign效率分别是8698/1351/453/206(个/s),verify效率分别是131847/46297/22970/13415。rsa也是随着内部状态上升效率下降的,而且下降非常快。而且verify效率远高于sign。 dsa 1024/2048的sign效率分别是9836/3280,verify的效率分别是10584/3616。 ecdsa 192/224/256/384的sign效率分别是12696/12672/21016/4383,verify效率分别是3200/5630/9994/1019。能很明显看出来,sign效率比verify高。256位的时候由于某种效应性能达峰,后续直接断崖下跌。 ecdh 192/224/256/384的效率为3642/8339/15094/1183。同样能看出这种效应。 rsa和ecc不具有互换性。rsa参数选择建议2048,ecc参数选择建议256。 对称加解密 openssl支持多种对称加密算法,可以直接对文件加解密。在使用前,我们首先列出系统上支持的算法。 openssl enc -ciphers 输出很复杂,不列举。我们直接讲我的机器上分析后的结果。 第一段是密码算法。在我这里,支持以下算法:aes, bf, blowfish, camellia, cast, chacha20, des, des3, desx, id(ea), rc2, rc4, seed。 最后一段有可能是模式。在我这里,支持以下模式:ECB,CBC,CFB,OFB,CNT。其中CFB,OFB和CTR(CNT)是可流式的,其余都是块式的。关于加密模式,可以看这篇。 在enc的manpages里明确说了,enc不支持CCM或是GCM这类的authenticated encryption。推荐是使用CMS。 例如我们使用比较流行的chacha20来加密一个文件src,里面可以随便写一句话。

Mar 8, 2018 - 2 minute read - Comments

密码学基本原理

Digest 摘要为一个函数H。对任意数据d,有h=H(s)。同时至少满足下面特性1。其余特性为额外要求。 对相同的数据d1=d2,计算得到h1=H(d1)和h2=H(d2),必然有h1=h2。但不要求h1=h2的情况下,必然有d1=d2。 根据h计算任意一个可能的d极其困难。(安全性) d服从随机分布的情况下,h的分布足够随机。(均匀性) hash系列函数 hash系列中最著名的即MD5,其后继者为SHA1,SHA2,SHA3等。但实际上这几个都是密码学hash函数。非密码hash常用于快速计算均匀散列值(例如hashtable),代表有CRC (实际上CRC主要的目地是校验,而不是散列), FNV,Murmur。这几个非密码hash函数的对比可以看这里。 hash函数需要注意长度。一般来说,长度越长越安全(越难被找到一个碰撞值)。但是过于长的值会在保存和使用上产生困难。 Rainbow table Rainbow table是一种通过预先计算来碰撞的手段。 从粗略的角度来说,你可以认为这就是一个巨大的反向hash表,保存了所有计算过的hash和对应的碰撞数据。但是通过计算可知,这样的反向表会占用巨大的存储空间。彩虹表采用巧妙的算法缩减了空间消耗。 其基础思想是,对某个碰撞数据,计算其hash,随后通过某个算法R,将这个目标hash再映射到另一个碰撞数据上去。通过这种方式,一个碰撞数据可以持续的计算出一串不同的hash。假设这个长度为n,我们最后保留最终一个hash和最初一个碰撞数据。 在检索某个hash的原始碰撞数据时,我们可以利用R将其映射为碰撞数据(但不是我们需要的那个碰撞数据),进而计算hash串并检测是否在反向表里。如果表里存在这个hash的碰撞数据,那么在生成n步的hash串的过程中,必然能在反向表里发现命中。而当发现命中后,就可以通过原始碰撞数据算出整个碰撞链,从而找到该hash的对应碰撞数据。 从算法分析的角度来说,这是一个空间换时间和时间换空间同时存在的巧妙算法。利用反向表计算原始碰撞是用空间换时间,用hash串来压缩空间消耗是用时间换空间。 另一个细节是hash链的碰撞。当hash链在某个节点相同,后续链条必然完全相同。这大大降低了hash串的效率。因此彩虹表采取了一个变形。算法R在n步中每一步都各不相同(实际一般是将n当作参数),这样使得hash碰撞只发生在一个点上。由于算法在每个步骤上各自不一,因而得名彩虹表。 KDF 密钥生成算法( KDF )是一类算法的统称,用于将一个密码/密钥变换成另一个(或多个)密码/密钥。在这个过程中,会提供很多额外特性。例如符合特定格式,防御暴力穷举攻击,保存后难于破解原始密码,等。 KDF的最知名场景,就是密码保存问题。用户的密码不应直接保存,这样在万一数据库泄漏时就会泄漏原始密码。而单纯hash会导致用户密码遭受彩虹表攻击。一般解决这个问题的方法是对密码加盐。但是盐是加在前面还是后面呢?以我个人的分析来看,似乎是没有区别的。即s+salt和salt+s都能保证安全。当然,更好的方法是用scrypt或bcrypt。他本身就有专门的函数保证密码安全保存,这可比加盐好使多了。 最佳实践 现在已经2018年了,我相信大部分读者都应该知道MD5和SHA1不安全的事了吧。这两者虽然还能完成摘要的用途,但是并没有安全保证了。如果你需要一个安全的hash算法,我推荐sha2。sha3目前并没有进入主流系统,而且执行速度还是略慢。 另外,如果有的选择的话,在sha2算法族里我推荐SHA-512/256或SHA-512/224。这两个算法有助于避免长度扩展攻击。 Encryption and Decryption 对称加密解密为一对函数,加密为E,解密为D。对任意数据d和密钥p,满足下面要求1和2。 加密为e=E(d, p),解密为d=D(e, p)。 攻击者得知E,D,e的情况下,无法反推d和p。 在条件2的基础上,攻击者能得知d和对应e的情况下,无法反推p。(已知明文攻击) 在条件2的基础上,攻击者能构造d并得知对应e的情况下,无法反推p。(选择明文攻击) 对称加密有几种可能的变形情况,例如E和D为同样的函数,一次加密第二次解密。或者由生成算法构造出密钥p和解密密钥p’。在其中密钥p可以推算变换为解密密钥p’。但这其实仍然符合上面的描述。因为解密时可以使用d=D(e, p'),而p'=G(p),因此d=D(e, G(p)),即可认为d=D'(e, p)。对于密钥p无法推算出解密密钥p’的情况,请参考下面的“非对称加密”。 DES/AES加密解密算法 加密算法中最有名的是DES和AES。关于这两个,我们不赘述。 密码模式 加解密算法一般都是以块模式运作的。即每个加密算法都有一个特定的长度,他只能处理这个长度的数据。块密码模式算法将基于某个特定的块算法,将其应用于流上。 最简单的用法是重复进行加密。取明文的前N字节加密,得到N字节密文。重复直到得到最后一块数据,数据的长度必然大于0小于N。对尾部的数据补足0。最后将所有密文联合起来,得到最终密文。这种模式叫做ECB模式。 ECB模式的好处是简单,但是ECB并不能防御内容替换攻击。攻击者可以通过某种方式获得一个数据的加密形式(选择明文)B’,然后将某个加密后的块B’替换原始块B。以此,虽然攻击者并不知道原始内容,但是可以替换其中的部分内容。 人们对ECB做了一点改进,使用上一个块的加密结果,对下一个块做干扰(具体使用XOR)。如此一来,对任意一个块的变更会导致后续块全部都无法解密。第一个块没有上一个块,也就没有加密结果。所以CBC需要一个初始向量IV来初始化干扰。而先加密上一个块的结果,再和当前数据XOR的算法,被称为CFB。CFB和CBC仅仅顺序上有区别,但是CFB可以用于流式加密,而CBC不行。因为CBC必须得到一个完整块,才能计算加密。而CFB预先算出mask,用XOR获得结果。 CFB再略变化一点,就可以构成OFB。OFB取的是XOR前的结果,因此加密序列并不受明文的影响,只受IV和key的影响。你可以想像,OFB是一个由IV和key已经决定好的,无限长的mask,逐步XOR到明文上。 但是CFB和OFB都有一些缺陷,例如明文和密文的异或对应性。在确定模式为CFB或OFB的前提下,对某些特定位置遍历所有可能空间,就能在不了解解密结果的前提下遍历所有明文可能性。这个问题被用于ss的主动探测上。 密码模式具体可以看这里。 Salsa20 Salsa20原来叫Chacha20,是一种经过特别设计的密码系统,在未经优化的CPU上拥有非常快的执行速度。 最佳实践 可能和大家想像的相反,一般没事不推荐直接使用加密函数本身,而是推荐使用AEAD算法。这里有一份2015年密码学最佳实践,按照推荐,是使用AES-GCM或Chacha20-Poly1305最好。这两种都是AEAD,具体下面有介绍。 如果一定要用加密算法,而非AEAD的话。推荐使用NaCl。它的加密算法默认选择是XSalsa20/20(Salsa20的一个变形)。 Message authentication code 消息验真,不同于摘要,要求的是拦截者无法伪造。其前提条件是发送者和验证者有一个共同的秘密p。本质上看,这个就是签署(sign)。但是一般我们讲sign都是指非对称的sign,MAC是对称式的。对称签署为两个函数,签署为S,校验为V。对任意数据d和密钥p。 对于签署获得的v=S(d, p),可以用V(d, v, p)来检验d和v是否成对。 攻击者在得知S,V,v,d的情况下,无法反推p。 签署算法经常和摘要算法合用,即对数据d先使用摘要H得到摘要,再计算签署。即v=S(H(d), p)。验证时使用V(H(d), v, p)来验证。

Jan 30, 2018 - 1 minute read - Comments

similan船宿

大致情况介绍 Similan archipelago,在Thailand,Phuket西北方一点的位置。要从Phuket坐一个多小时车,到一个叫做Khao Lak的地方。然后再坐船出海,走大概两三小时。地图上看,在Thailand的外海,离海岸50公里以上。(这应当是公海了吧) 潜店和船 我们是让朋友报的船,到了才知道,潜店是这家Khaolak Scuba Adventures,船是三天三夜的一艘Manta Queen 5。船宽5米长26米,推荐容纳20人,实际容纳22人。推荐船员5人,实际7人。推荐潜导5人,实际7人(含manager)。 这艘船,怎么说呢,家吉一看就觉得很坑爹,我觉得还好吧,毕竟这个价格。船舱里面是上下铺的床,都是软垫铺一层床单,加一个枕头和被子。床很小,大约60-80公分宽,2米长。趟下去顶天立地,横向只够翻身,高度不够坐起。船舱里有空调,但是只有晚上打开。平时只有头上的一个风扇。幸好电倒是24小时提供,足以充手机和相机。然而这一路上都没有信号。 这也不难理解。Similan离最近的陆地超过50km,而普通手机信号只能传播20km左右。再加上按照地球弧度,50km造成的高度差会高达200m左右(6700*(1-math.cos(50⁄20000.0*math.pi))*1000,不知道我有没有算错),信号塔不在山上的话,无线信号会直接被海水阻挡住。所以整个船宿过程是没有信号的。 我们说回船。一层前半部是8个船舱,中间是三个浴室兼厕所,后部是潜水装备间。二层前半部是船长室和4个船舱,后部是公共空间,一般在这里做brief或者吃饭。三层是Sun deck,带一个顶棚。我们经常在潜水间隔跑去Sun deck那里晒太阳。冬天Similan的水还是有点冷(28左右吧),晒晒太阳有助于蒸发水分补充热能减少寒冷。 这里要说说厕所。船上的厕所都是直排的,你的排泄物会直接冲到海里。所以如果有什么可能导致问题的东西(例如,纸巾),必须丢到垃圾桶里。有一次某个客人的纸巾丟到马桶里了,结果一个厕所就无法使用了。我们还只有三个厕所,每个都是厕所/浴室/面盆的合体(地方也不是一般的小)。一旦碰到早上起床,潜水前后。厕所前排长队是意料之中。所以那次厕所出问题后,基本每次高峰时刻,厕所前面都会排上一个小时左右的队。 航程 我们是晚上9点左右上船的,经过一个简短的brief就开船了。Manager是一个俄罗斯妹子,声音比较沙哑。晚上经过两个多小时的晃悠,我们到了Similan群岛附近的一个地方停泊。 睡过一晚上后,早上6点起床做brief,下水check dive,吃早饭。休息一小时顺便换个地方,再下一支,起来吃午饭再休息一小时。下午下一支,起来休息两小时再吃个晚饭。晚饭后大家聊聊天,再下一次夜潜,第一天结束。 第一天我碰到了剧烈的头痛,推测是在第二或第三潜的时候上浮过快导致。一旦产生气泡,要消解起来就要好几小时的排氮。所以夜潜的时候都在头痛,直到夜宵结束后才逐步减轻。所以大家要小心上浮速度问题,非但不要超过18m/min,最好控制在9m/min以内,甚至短距离内也不要放松。 这次潜水我全程使用高氧,一支大概要150THB,合30CNY。全程总计300CNY,我觉得挺便宜。原则上说,这让我全程舒服很多。至于头痛,只能说大概我控制的还不够好。 潜点我就不一一列举了,反正你们也没得选。大致来说,1.1左右Similan水温28左右,不需要湿衣。天气晴,偶尔有小雨。海浪一般。大部分时候是没什么感觉的,只有一次例外。当然,开船的时候晃动还是比较猛烈的。 第二天就是晕船。早上起来,船长泊在一个面向波浪,靠近岛礁的地方休息,等待等会潜水。(海浪也是有传递方向的,一般船长会选择泊在岛背面,减少波浪)结果海浪加岸边的波浪反弹把我晃晕了。早上一支结束后,难受的生不如死,就吃了一颗晕船药,放弃一支潜水,躺在船舱里睡觉。他们上来后,船长就开始换地方,我继续睡觉。等突然就有船员很开心的敲门,Dolphin!我大概也好的差不多了,跑到Sun deck那就开始观望海豚。一群海豚追逐着我们和隔壁一艘潜水船,不断盘旋和跳出水面,大概跟了半个多小时。船长还特意偏出部分航线来追海豚。可惜跑的太快了,忘记把相机拿出来,结果没照片,只能等同船的人发给我(如果他们还记得的话)。 至于晕船,我了解到一点。不是我不会晕,只是海浪还不够大。后来我就聪明了。凡是这种有晕船可能性的情况,统统先吃再说。 第三天去北边的Koh Bon那。我们早上第一支下去的时候,有个团友就看到了Manta,但是他没有叮叮。潜到一半的时候,潜导把我们集体敲起来看Manta。我们集体连气泡都不敢吐,就看着一只巨大的Manta从我们头顶飞过。旁边还有几条大鱼(当然,和Manta本身大小比起来是大大不如)。上水之后,把同船的人羡慕坏了,我们Team直接变成了Manta Team。不过第二支的时候,我们在一个山脊侧面遇到1-2节的对向流。潜导看我们踢的很辛苦,就斜切避开了。后面几个Team就直接顶流,最后Drift。所以他们上水的位置比较靠外,我们是在Bay里面上水的。他们上水的时候又看到了Manta。 好吧,这样也是蛮公平的。 另外就是回程路上,我们最后一支是在回程一半的地方,Wreck Dive。尼马Wreck我见多了,但是这么多鱼的我还是头一次见到。能见度不高,只有10左右。但是整个行程基本都是在鱼类瀑布里面游动。就看到无数鱼围着你转圈圈。上来之后我们在那里吐槽,为啥海洋中间能见度那么差?那TM都是鱼类的粪便。 上陆地后事情就乏善可陈了。在Phuket住了一晚,早上坐L家的车到了Samui,晚上在Samui吃了点东西(下船的时候正好大雨,等我们住下,雨停了)。再一个早上坐另一艘船到了Koh tao。 Koh Tao Koh Tao算得上是我和家吉的老地盘了,这次还是到Crystal。他们的宿舍修好了,就在学校隔壁。很近不说,还有空调,1000THB一天。 这次去Crystal,是考Deep Dive。这次搞明白了一个问题。在AOW的时候,我们不是有五个专长么?其实在AOW的时候,我们并不是修完了5个专长,而是每个专长只上了一节课。所以AOW修完,我们是没有专长证的。但是在AOW时附修的EAN,是专门的两支,所以有专门的证。AOW的这五节课只给了我们两个好处: 部分的专长能力。例如深潜,AOW必修课,给我们30米深度许可。 在考对应专长的时候,能少上一次课。 所以,这次的深潜专长,经过三次大深度潜水(至少一次30米以上),和一次额外辅助减压(抱气瓶),许可我潜到40米深度。但是不得不吐槽一下,在仔细查过之后,我发现这个证并不是特别有用。因为: 很多保险并不支持40米深度。例如美亚,要求你在证件许可下,30米深度内活动。所以30米以下深度潜水是无保险的(而且可能会连累你之后的潜水全都没有保险)。 40米深度并不是谁都能去的。如果你的潜导,全组潜伴并不是都有这个证,你就下不去。 EAN下40米深度的配套很不友好。EAN32的最大深度是32-33米,要下40米深度,需要用EAN28。但是EAN的标准是32或36(左右),很多地方并没有28,例如Crystal。这导致这种大深度潜水反而必须使用空气,其实非常消耗No Dec。老潜水员知道,大部分高强度潜水的时候,No Dec才是瓶颈。 30-40米深度可见生物更少。这个深度生物体积更大,出现几率变少,基本都是博人品的重复潜水。 所以,如果考专长的话。你们可以考虑一下Deep Dive是不是值得考。以下是我觉得还不错的几个证,有机会可能会考: Wreck。绑线进去的那种,汗。要求15以上,AOW。 Sidemount。15岁以上,OW。 Dry Suit。10岁以上,OW。这个在潜冷水的时候是必需品。 Rebreather。18岁以上,OW,EAN,最低25潜。这个要求挺复杂,但是主证到不用AOW(实话说EAN+25logs其实是超过AOW的)。CCR在大深度还是比较管用的,而且下去不会有气泡惊到鱼群。 其中,Sidemount,Drysuit,Rebreather都是需要考虑是不是能在潜店租到装备的。也欢迎考过上述几个证的朋友给予意见,是不是值得。起码EAN是非常值得的一个证。 另外两个非专长的课,我有计划去上的。 Rescue。要先考出EFR来。但是我挺不喜欢中红会。 GUE Fundamentals。俗称馒头课。从我看到的数据来说,PG就可以上。 最后说一下这次考证的几个细节。

Dec 17, 2017 - 1 minute read - Comments

在云存储上叠加加密文件系统

目标很简单。云存储上很多文件都挺私人的,直接放着很吓人。虽说云存储采用各种方法来保证你的安全,但是世界上没有绝对的安全。万一密码泄漏,或者更糟糕,云存储泄漏。此时你的各种文件就在网络上裸奔了。 最简单的解决方法是什么?在底层存储上套一层加密呗。不过由于是云存储,所以基于块设备的加密方案不能用,例如LUKS。否则你同步到云上的就是一个超级巨大的块文件,然后每次修改,云存储客户端都要找到差别上传。这太蛋疼了。正解是每个文件分别加密上传。但即便如此,对于超大文件进行加密后依然会影响上传效率,请提前考虑一下这个问题。 同时又要注意,云存储用的加密文件系统和普通的加密文件系统还有点差别。很多加密文件系统的daemon会认为自己是唯一一个会访问加密内容的进程,而云存储可能随时接收来自远程的修改。所以这会造成一些问题。 备选方案 我对比了四种方案,EncFS,CryFS,GoCryptFS,eCryptFS。对比的方法是用这四种分别建立一个加密目录,然后用不同的方法做写入测试,看他的各种参数。顺便说一句,如果你要看的话,其实看这份表格就好。我只是在自己的机器上复现了一下,顺便了解一下各家特点。 测试语句: time dd if=/dev/zero of=test bs=1048576 count=1024 time dd if=/dev/zero of=test bs=1024 count=1048576 time tar xf linux-4.13.12.tar.xz 其中,在裸盘上直接解压内核源码耗时7.568s,空间使用870M。 数据对比 +---------+-------+-----+-------+-----+-------+-----+--------------+ | |time1 |size1|time2 |size2|time3 |size3|comment | +---------+-------+-----+-------+-----+-------+-----+--------------+ |EncFS |13.210s|1.1G |39.039s|1.1G |26.496s|894M | | +---------+-------+-----+-------+-----+-------+-----+--------------+ |CryFS |9.327s |1.1G |21.230s|1.1G |42.918s|2.5G |删除耗时2.804s| +---------+-------+-----+-------+-----+-------+-----+--------------+ |GoCryptFS|3.515s |1.1G |28.180s|1.1G |19.874s|918M | | +---------+-------+-----+-------+-----+-------+-----+--------------+ |eCryptFS |3.132s |1.1G |10.218s|1.1G |9.448s |1.4G | | +---------+-------+-----+-------+-----+-------+-----+--------------+ 解读 首先说怎么解读。time1是连续写入性能,time2是离散写入性能,time3是小文件写入性能,size3是大量小文件膨胀系统。size1和size2没啥用。 下面先看性能。从性能上看,最优秀的是eCryptFS。这是理所当然,因为这是唯一一个内核态而且和内核整合的系统。GoCryptFS次之。EncFS要慢上好多。至于CryFS,一开始写小文件就原型毕露了。何况这是唯一一个删除大文件时间超过1s的,达到2.8s。你看我其他系统测试里都没写。 然后是膨胀率。EncFS膨胀2.75%,CryFS膨胀近三倍,GoCryptFS膨胀5.52%,eCryptFS膨胀65%。相比起来,EncFS膨胀率最小,GoCryptFS次之,CryFS最糟糕。 安全性 下面是同一个人出的三份审计报告:

Nov 22, 2017 - 1 minute read - Comments

京都游记

细节不说太多了,京都毕竟是一个挺现代化的城市了,又不是什么荒郊野外。我只说几个特别的建议吧。 京都公交一日卡非常便宜,只要500JPY。如果单独坐车,一次230JPY,所以三次回本。但是公交日卡和铁路日卡是分开的,一起买1200JPY。公交日卡地铁站就有卖,铁路日卡铁路那里没得卖,你最好趁早在京都站搞定。公交日卡不需要写日期,头次用会塞到机器里打印一个日期,第二次起直接给司机看就行。啊,对了,这些卡都有使用范围限制,具体查一下。 大部分公交都是后门上前门下,下车付费,不设找零(但是1000JPY以下有自动兑换机)。部分车上车的地方有个刷卡机,那就可以分段计费了。但除非是照顾对象,请不要坐优先席。 强烈推荐Hot Pepper这个应用。可以指定一个区域,搜索平均费用在什么区间的一个什么类型的饭店。我用这个找到了几个不错的店。不是说特别好吃,京都的店都不差,就算街上随便碰也都不错。而是说没有这个应用我找不到店,或者店不合适。例如仁和寺门口,有个挺便宜的小店,叫篝・喫茶,旁边还有个咖喱店。但是这要走两步。如果你没看到,直接进了门口的佐近,那就走的远了。我相信东西会好吃很多,可是价钱也会贵一些。 机场的商品种类不多,而且价格不一定便宜。有的便宜了,有的反而贵。最简单的办法是在市内的免税店把东西都买好,过机场的时候把免税单一交就行。 不要担心语言问题。只要有钱,你不说话都行。不过想省钱,还是把日语学学好。

Nov 6, 2017 - 1 minute read - Comments

Boracay潜水攻略

大致情况介绍 Boracay,菲律宾长滩岛。关于菲律宾的基础信息不介绍了,这篇里面都有。我们就说一点当地的东西吧。 我们主要在西边活动,东边没怎么去,据说不太平。Boracay西边有个贼长无比的海滩,一条繁华的海滩商业街就沿着那里展开。初此外还有一条主路。基本你就沿着这两条路走,一定能找到你要去的地方。海滩商业街上有很多店,基本都是餐饮,按摩,小商品,潜水,辫子,纹身。我们所说的大部分店,都在海滩边上。如果不在,我会特别指出。 潜店 Boracay的潜店一大堆,我随便走走都能看到10多家。但是在padi上注册过的并不多。我这里看到的idc有Calypso Diving School International和Sea World Dive Center。从padi上看,watercolors也是idc。但是他的注册位置和实际位置不大一样。其他的都不是idc,或者没有在padi上注册过。 Sea World我路过去看过。当时打着中文广告,我还以为是中国人开的,结果是韩国人开的。广告很NB,岛上唯一一家五星IDC。岛上究竟几家上面我都列出来了。不过不说别的,他们的位置和店面都很不错。而且店员会中文,这点对很多人很有用。 Boracay的价格基本都稳定下来了,FD标价都在1800PHP左右,偶尔能见到1900,比较贵。我选的一家是朋友推荐的,老板是韩国人(很帅的欧巴哦)。标价都是1800,去了才发现地方略偏,但是有好处的。除了两潜外,潜导都是1对1服务。不过最后一天我才发现,两个潜导一个SSI一个CMAS。幸好我有一支和老板一起下水了,所以让老板给我签个PADI的,好规避review问题。 最后说一点,DSD。岛上的DSD才是最大的潜种,而不像有些地方,基本都是FD。这很好理解,Boracay是一个休闲旅游岛,而不是一个专门潜水的岛。在我选的这家店里,有次我看到十多个人在那里做DSD培训(店里有人会中文),出去的时候还要加十个左右的instructor(有负责照相的)。30个人浩浩荡荡两条船跑出去。 做DSD的(虽然我估计DSD不大可能来我的blog,会来的不是程序员就是老潜水员)请千万注意几个问题。DSD最主要的安全问题是什么?潜导不足潜导违规。只要配够instructor按规定操作,DSD几乎没有风险。说几乎是因为,就算平地走路都可能被雷劈死,跳到海里去潜水不会更加安全的。因此体验潜水一个强制要求是,instructor和潜水员比例不得超过1:2。 这两天闲聊的时候,我听到的范围里,所有潜店都坚持了这个比例配置。但是如果坚持这个比例,你就可以算出来,做DSD好像还没有FD赚啊(1:1的这种FD不谈)。所以很多DSD有一定的玩花样的成分。例如水下配个AOW下去给你照相,回头卖你相片。还有气不给打足,20多分钟就可以上来了。当然,万幸的是,好歹大家节操还比较足,不会出现耳压培训不做就踢下水,然后等你受不了升水的情况(三亚名产)。 潜点 Boracay通常流都不大,因为大部分情况下洋流都是东西向的,而岛是南北向的。因此在西面大部分时候都没有流,或者小流。在岛的最南和最北有大洋流,所以去的人很少。西面大部分时候都是南向北或者北向南的一节流。人类活动较多,水下能见度一般。 照片在这里。 Camia Wreck 11° 57.115’ N, 121° 54.523’ E Max: 28.4, Avg: 19.5, Vis: 10+, Current: 1 海滩正对面的一个沉船,没啥好多说的。有几条非常大的鱼,品种搞不清楚。中间船舱有个地方能沉下去,然后穿过大约3-5米的封闭船舱(警告:这是潜水违规操作),右转上升出舱。中间距离非常大,对脚法没有要求。这个点有种非常大的鱼,谁知道是什么? Angol Point 11° 56.828’ N, 121° 55.2’ E Max: 14.3, Avg: 7.9, Vis: 10+, Current: 0 海滩对面的浅点,非常容易。基本就在里面玩了一阵而已,没啥难度。照到了三个海兔排排坐。另外,下去之前我的reg的O-ring爆裂了。 Friday Rock 11° 58.083’ N, 121° 54.263’ E Max: 17.4, Avg: 12.8, Vis: 10+, Current: 0

Nov 1, 2017 - 1 minute read - Comments

golang安装和编译环境搭建

我本来以为是个挺简单的问题,结果实践一下发现还是挺多人不明白的。所以我写一下。 安装 挺简单的。你在golang.org下载一个合适的安装包,回来之后找个地方解开——例如~/usr/share/go这个目录。 而后你需要调整两个变量,GOROOT和PATH。PATH是必须调整的,GOROOT原则上可以不管。当你使用了正确的go程序后,GOROOT会自动设定。但是我习惯先设定GOROOT,然后计算出PATH。像下面这样(注意环境变量里要用绝对路径,不要用~)。 export GOROOT=/home/user/usr/share/go export PATH=$GOROOT/bin:$PATH 一般我会将这个设定设在bashrc里,变成我私有的设定。这样不会对系统产生干扰。在经过这个设定后,你需要让所有bash载入这个设定。最快的是重启,不喜欢动静太大的可以source ~/.bashrc。载入完成后,你可以试试go version,看看是否生效,版本是否正确。 配置环境 golang的编译环境配置只需要配置一个变量,GOPATH。例如我将GOPATH设定到~/usr/,在bashrc中加入export GOPATH=/home/user/usr,那么源码路径就是~/usr/src。将来下载的所有包,都会根据这个位置自动计算路径。例如http2的包,名字叫做golang.org/x/net/http2,下载时的路径就会是~/usr/src/golang.org/x/net/http2。你可以用go get golang.org/x/net/http2来自动下载这个包。 如果你自己开了一个项目,那么你需要搞一个url,例如github。然后把你的项目放到对应路径——例如~/usr/src/github.com/username/project。然后在这个路径下做所有操作。最后你可以使用go build package编译它,非常容易。 install golang除了源码之外,还有很多的编译结果。例如go项目自己的源码在~/usr/share/go/src/下面,可执行文件在~/usr/share/go/bin/下面。而你和你下载的各种项目的编译结果就在~/usr/bin/下面——是不是觉得和linux的文件管理方式非常像? 所以上面的bashrc配置还需要做一点调整,以便让你除了能用go做编译外,还能直接使用go编译出来的项目。 export GOROOT=/home/user/usr/share/go/ export GOPATH=/home/user/usr/ export PATH=$GOROOT/bin:$GOPATH/bin:$PATH