捡垃圾DIY高性能黑群晖家庭NAS

发表于2021-03-12由daniel

虽然网络重重受阻，但一直是 Google Photo 的忠实用户，原因有很多，比如智能相册，每到一个地方游玩回来，自动生成一个相册；比如智能滤镜和历史推荐，每每在不经意间震撼到你，流下时间的眼泪。当然，最重要的原因应该是无限容量的高质量存储。

然而，这个优势将在2021年6月1日终止：

Starting June 1, 2021, any new photos and videos you upload will count toward the free 15 GB of storage that comes with every Google Account or the additional storage you’ve purchased as a Google One member. Your Google Account storage is shared across Drive, Gmail and Photos. This change also allows us to keep pace with the growing demand for storage. And, as always, we uphold our commitment to not use information in Google Photos for advertising purposes. We know this is a big shift and may come as a surprise, so we wanted to let you know well in advance and give you resources to make this easier.

也就是后续新长传的照片和视频将不再享受无限容量，每月100GB的价格是1.99刀（很良心的价格）。看到这个消息的时候，虽然有失望，但更多的还是惋惜和感谢。如果免费存储这条路连谷歌生态中也无法实现，那应该也不会有第二家公司能支撑起这种商业模式，感谢对过往历史的忠实记录。

付费的价格是并不高，但是考虑到家里父母手机相册备份问题，索性这次就自建NAS把家人的数据备份问题都解决。

黑群晖方案配置

因为目的是备份照片，因此需要在手机上有友好的app支持。这样的话FreeNAS和OMV就是被排除在外了，几乎只有群晖一个选项。然而，白群晖的性价比实在让人提不起兴趣。正好手痒，捡了一些洋垃圾DIY的一个黑群晖，花了不到一半的价格，性能确是918+性能的两倍以上：

准系统: ThinkPad P300, ￥390
CPU: 奔腾G220, ￥40
内存: 金士顿4G, ￥56
硬盘: 希捷酷鹰4T, ￥488
系统盘: 酷豆16G, ￥24
总计：￥998

为什么选了一个 SFF 4代酷睿的准系统？

牙膏厂酷睿4~7代基本没啥区别，但是4代准系统和内存便宜。ThinkPad P300算是这里面比较贵的，主要原因是以前是ThinkPad的脑残粉，P300颜值要高出其他品牌一个level:

为了颜值，除了牺牲价格，还有就是扩展性。P300算是光驱位替换，只能塞下两块3.5+一块2.5硬盘。但对于我来说，一共也就6部手机需要备份，一共不到2T，一块硬盘就足够了，扩展性的短板也就不是问题了。

如果极致追求性价比，可以考虑惠普z230，300左右可以拿下，最多可以扩展3块3.5硬盘。

为什么是标压CPU?

NAS全天候开机，需要考虑节能，这并没有错。选择标压CPU也没有错。因为CPU的TDP只是一个参考，低负载运行的时候，主要是CPU的核数影响功率，G3220是一颗双核CPU，待机功耗低，而在转码等需要性能的场景有可以提供足够的性能，CPU MARK得分是918+的两倍还多，而且核显支持硬解。实际测试功耗只有20w:

为什么选择酷鹰，而不是烂大街的酷狼？

其实主要是非叠瓦盘就可以了，酷狼酷鹰只是一个渠道概念，产品没什么区别。价格上酷鹰便宜一大截。不过最近日立的监控盘价格只需要300多，也可以看看。

黑群晖如何装？

网上教程太多了，随便找一个吧。

如何开启公网访问NAS？

因为是黑群晖，又不想洗白，那么外网访问可以通过DDNS+宽带公网IP了。

只有一块硬盘，那就是没有用RAID喽？

是的。我对这台NAS的职能定义很简单，就是备份。容灾的话，RAID是可能的方案之一，但是对于家庭用户却是一个挺鸡肋的方案。因此，我选择定期用移动硬盘拷贝备份NAS硬盘做灾备。

网络只有一个千兆网卡？

是的。只有一个机械硬盘，又没有SSD缓存，一个千兆网卡足够了。如果是当做视频剪辑NAS使用，系统建议就使用FreeNAS, 然后通过PCIE插槽扩展万兆网卡，内存至少32G.

1024搬砖之IG密码加密方案分析

发表于2020-10-25由daniel

10.24本来是普通的日子，但却有机会让你很容易的区分的两种人：程序猿与其他。

正好周六，于是把之前 side project 中的一个临时方案修改一下。其中一个关键问题点是：用 go 生成 Instagram 登录时需要用到的加密密码。

C# 版本代码如下：

public static string GenerateEncPassword(string password, string publicKey, string keyId, string version)
{
var time = DateTime.UtcNow.ToTimestamp(); // Unix timestamp
var keyBytes = publicKey.HexToBytes(); // Convert a hex string to a byte array
var key = new byte[32];
new Random().NextBytes(key);
var iv = new byte[12];
var tag = new byte[16];
var plainText = password.ToBytes(); // ToBytes = Encoding.UTF8.GetBytes
var cipherText = new byte[plainText.Length];

using (var cipher = new AesGcm(key))
{
cipher.Encrypt(nonce: iv,
plaintext: plainText,
ciphertext: cipherText,
tag: tag,
associatedData: time.ToString().ToBytes());
}

var encryptedKey = SealedPublicKeyBox.Create(key, keyBytes);
var bytesOfLen = ((short)encryptedKey.Length).ToBytes(); // ToBytes = BitConverter.GetBytes(short);
var info = new byte[] { 1, byte.Parse(keyId) };
var bytes = info.Concat(bytesOfLen).Concat(encryptedKey).Concat(tag).Concat(cipherText); // Concat means that concat two array

// expected: #PWD_INSTAGRAM_BROWSER:10:1595671654:ARBQAFWLYGkTT9UU0dyUCkaGTRFu0PH5Ph5s86DUAbZ+B9xon8cKmnqQGaUo7bB4NHCMKQRY69b9LwaJZ1rDw1OFM0LEGtI+KbDuDC0QnfJM6o1no0XPOl73RJoUZ/OfN5nE2q/IdqX0NFinS0faRf8=
var str = $"#PWD_INSTAGRAM_BROWSER:{version}:{time}:{bytes.ToBase64()}"; // ToBase64 = Convert.ToBase64String
return str;
}

public static string GenerateEncPassword(string password, string publicKey, string keyId, string version)

{

var time = DateTime.UtcNow.ToTimestamp(); // Unix timestamp

var keyBytes = publicKey.HexToBytes(); // Convert a hex string to a byte array

var key = new byte[32];

new Random().NextBytes(key);

var iv = new byte[12];

var tag = new byte[16];

var plainText = password.ToBytes(); // ToBytes = Encoding.UTF8.GetBytes

var cipherText = new byte[plainText.Length];

using (var cipher = new AesGcm(key))

{

cipher.Encrypt(nonce: iv,

plaintext: plainText,

ciphertext: cipherText,

tag: tag,

associatedData: time.ToString().ToBytes());

}

var encryptedKey = SealedPublicKeyBox.Create(key, keyBytes);

var bytesOfLen = ((short)encryptedKey.Length).ToBytes(); // ToBytes = BitConverter.GetBytes(short);

var info = new byte[] { 1, byte.Parse(keyId) };

var bytes = info.Concat(bytesOfLen).Concat(encryptedKey).Concat(tag).Concat(cipherText); // Concat means that concat two array

// expected: #PWD_INSTAGRAM_BROWSER:10:1595671654:ARBQAFWLYGkTT9UU0dyUCkaGTRFu0PH5Ph5s86DUAbZ+B9xon8cKmnqQGaUo7bB4NHCMKQRY69b9LwaJZ1rDw1OFM0LEGtI+KbDuDC0QnfJM6o1no0XPOl73RJoUZ/OfN5nE2q/IdqX0NFinS0faRf8=

var str = $"#PWD_INSTAGRAM_BROWSER:{version}:{time}:{bytes.ToBase64()}"; // ToBase64 = Convert.ToBase64String

return str;

}

扫了一下整体结构，发现IG的这段加密设计还是很好的体现了大厂典范：

密码加密使用到了 aes-256-gcm, 不是野生程序员上来就是base64或者来一个自欺欺人的哈希函数（MD5, SHA1等）。这两者本身不应该一起提，因为本身是用途完全不一样的东西，只是国内看过很多方案是后者，有时候还觉得自己加了salt更安全。AES结合GCM在解决数据加密问题的同时，也解决是数据完整性校验的问题。此外，加密操作中引入time作为附加数据，因此也可以校验数据的时效性，防止重放攻击。
AES是一种对称加密，因此涉及的密钥分发的问题。上述方案中，使用了SealedPublicKeyBox 这种常用且规范的源于。即通过接收者的公钥来解密AES的对称密钥，得到密钥的密文。而这个密钥密文只有接收者使用自己的私钥才能解密。
从私钥密钥去中心化以及管理维护成本出发，应该是同时启用了多对公私钥对(可通过keyId识别)。
密文bytes构造上采用经典简洁的length.content设计。
最终构造的 enc_password 格式中包含了平台、版本、时间戳、密文。如果你也设计过密码加密的方案，你应该能看到这几个要素没有一点废话，基本就是教科书的标准格式示范。调研了一圈，发现的唯一业务上的槽点是版本为某个特定值时，其实是允许传输明文密码的。这从语义上来说是矛盾的，推测是从前向兼容的一种妥协。
golang中可以通过 NewGCM 实现 aes-256-gcm, 但是认证标签(authentication tag) 没有单独输出，是append在密文之后的。因此可以通过 cipherText[len(cipherText)-16:] 获取。
golang中没有 SealedPublicKeyBox 原语。可以用 package golang.org/x/crypto/nacl/box 中的 SealAnonymous 代替。

其实密码加密方案有很多基本的概念和原则，国外大厂也有很多规范的设计。只要不是一开始就想当然，其实是能找到或者设计出一个符合业务需求且安全高效的加密方案的。

特殊的一天，在老家楼上分析了一段有意思的代码，完整了方案的重构，还开着遥控车在农村撒欢越野。 What a beautiful day!

九月总结及阶段思考

发表于2020-09-30由daniel

9月最后一天，开完最后一个会议，早早的从公司溜了，顺便突然出现在妞儿单位的停车场给她个惊喜，同时实现一下接女儿放学的小小心愿，这应该是9月份最开心的事了（还真是枯燥无味，朴实无华…）。

9.30意味着S1财年结束了。转瞬间，两年过去了，很多事情无论是经历的业务还是心路，过去的半年比过去的一年似乎更多更长，有着别样的滋味。

合作关系上一直比较幸运，少有的低谷也在不知不觉间得到了扭转。感恩这种幸运，同时也感谢自己一直坚持的信用价值。否则我相信纵使有更多人从身旁路过，也只不过是一个过客。

过去两年的主题一直是在找寻成长。但讽刺的是，从blog看，技术输出明显变少了。如今对于这一点已经非常坦然了，我相信技术出生的同学依然会介意这一点，因为技术上的学习和成长很容易从对比中去量化。人们对于可预期，强反馈的事物总是非常有执念。

然而，个人的成长远不止技术成长。其他层面的成长反而是非常难以标定和量化的。因此，过去一年，我一直在尝试通从别人眼中照镜子的方式来衡量自己的成长。这种照镜子一方面是你能够成就自己的同时，也能成就他人，并且这种成就有时候可能对你短期来说是有损的。比如，你闪光的idea、plan中关键的环节，这些你是否愿意交个他人，同时在一定程度上退身，兜底的是你，上台领奖交给他。坦率讲，我说的这些在过去的一年之于我不是“比如”，而是事实，我也并不是慈善家。但是，我出奇的发现，你在意的人其实是能够看清这背后的逻辑关系的，你的退身反而是价值和口碑的积累。

其次是要在你的关系网络中找到关键点。很多人谈中年危机，其实本质上都是因为他在他赖以生存的网络中出了问题，而这一切跟年龄无关，如果一定要说有什么关系的话，只是年轻的时候输了一局你还有下一局。从这点看，无论你是要在技术领域深入成为不可替代，还是在业务层面八面玲珑，四处延伸，本质上都是提高你在生存网络上的附着力。

最后是要充分理解精致利己主义者，这其中包括你自己。我一直认为个人的成长是内环境熵减的过程，如果你成长的速度高于平均，那么周围环境之于你就是一个熵增的过程。因此，但凡是在平均线以上，无论你主观如何认知和解释，本质上你都是在利己的同时在损人。而对于成长速度不在一个层次的人来说，彼此就是彼此的熵增和熵减。从这点看，个人成长跟不上公司发展速度的、夫妻二人成长速度差异太大的，最终只能分道扬镳。而我们可以做的就是不断的迭代中，无论是熵减还是被熵增，保持平和的心态，以及持续对抗的态度。

岁月无静好，希望至美！

行思錄 | Travel Coder

Arch, Coding, Life

分类目录归档：SiteLog