[建议]下架第三方插件 cryptsidian

建议反馈
1

不能理解为什么会有这样的插件存在，
加密文件如同儿戏，

最离谱的是“如果您使用不同的密码进行加密和解密，您的文件将会损坏。”

请问一下，这里面向是保存国家机密文件的用户吗，解密输错一次密码文件就损坏无法恢复。

在插件市场上能直接搜索并安装这样的插件，是对用户的不负责任。

最最离谱的是，

作为一个入门教程，居然给用户推荐这样的插件，除非你是想给新用户一个教训，必须提前备份文件。不然的话，推荐这样的地雷插件对新用户有什么好处呢

2

这是超市里卖菜刀。菜刀厂家说操作不当会切到手指或伤人。逛超市的人看到了，怪超市卖菜刀，对顾客安全不负责。
都是成年人了，要自己的选择自己负责，不迁怒

3

已反馈官方。

不过不管是新手还是老手，在关闭安全模式安装插件前，都不要忽视风险提示啊。

image
image1122×540 31.4 KB

2 个赞
4

你说的对，但是作为一款对新手推荐的插件，输错一次密码就会导致文件毁损，你觉得这合理吗

5

人家也写清楚风险了呀，这只是个人用户分享经验，这都要审判吗

6

唉, 看着揪心…

Obsidian 的核心插件 “文件恢复” 可能是默认开着的, 可以去试试运气
操作是: 快照 → 浏览 → 鼠标点 “请选择文件” 那个框


查了插件的说明, 人家确实注明了风险, 一上来就提示 使用前要备份
后面还写着几条:

  • 加密后, 不要在 Obsidian 或其他应用程序中打开文件
  • 它应该可以在 Windows 上运行, 但尚未经过测试
  • 该插件尚未经过独立的安全审核
  • Obsidian API 的未来更改可能会破坏此插件, 不保证向前兼容性

说实话, 这插件作者叠甲叠的可以了


我实际测试了下:

能用, 不好用

在小心的正确操作场景里, 仍有这么个问题: 插件机制是加密后, 原位 (in place) 替掉旧文件, 意味着这时候, 一整个仓库的顶着 *.md 后缀名的看似文本文件, 实质全是二进制的密文, 但 Ob 是不知道这事的, 一旦打开这些 md, Ob 就尝试给你保存为 utf-8 文本 (可能导致密文内容变化)

上述这条, 即使是作者明确写了要注意, 用户也难免会误操作的


解密输错一次密码文件就损坏无法恢复

插件用的加密算法是 aes-256-ctr, 如果楼主是如下操作的:

  1. 使用自己密码 correctkey 加密
  2. 使用误拼密码 wrongkey 解密

在同时拥有

  1. correctkey
  2. wrongkey
  3. 以错误密钥解密出来的伪原文

时, 理论上可以恢复出原文的

给个简单示例

伪原文 还原 代码示例 
from Crypto.Cipher import AES
from Crypto.Util import Counter

def encrypt_aes_ctr(key, plaintext, nonce):
    ctr = Counter.new(128, initial_value=int.from_bytes(nonce, byteorder='big'))
    cipher = AES.new(key, AES.MODE_CTR, counter=ctr)
    return cipher.encrypt(plaintext)

def decrypt_aes_ctr(key, ciphertext, nonce):
    ctr = Counter.new(128, initial_value=int.from_bytes(nonce, byteorder='big'))
    cipher = AES.new(key, AES.MODE_CTR, counter=ctr)
    return cipher.decrypt(ciphertext)


plaintext = b"Sensitive data that needs encryption"
nonce = os.urandom(16)  # 128-bit nonce
correct_key = os.urandom(32)  # 256-bit密钥
wrong_key = os.urandom(32)  # 256-bit错误密钥

# 正确加密
ciphertext = encrypt_aes_ctr(correct_key, plaintext, nonce)
# 错误解密，得到无效原文
invalid_plaintext = decrypt_aes_ctr(wrong_key, ciphertext, nonce)
# 恢复密文
wrong_key_stream = encrypt_aes_ctr(wrong_key, b'\x00' * len(ciphertext), nonce)
recovered_ciphertext = bytes(a ^ b for a, b in zip(invalid_plaintext, wrong_key_stream))

# 使用正确密钥解密恢复的密文
recovered_plaintext = decrypt_aes_ctr(correct_key, recovered_ciphertext, nonce)
print(f"Original plaintext: {plaintext}")
print(f"Recovered plaintext: {recovered_plaintext}")

以上这段实测可用,

实际操作会更复杂些, 比如这插件的 iv (初始向量) 不是固定的, 是随机生成 16 字节, 拼接在密文前面



写太长了, 总结一下自己观点

  • 自己对数据安全负责, 别人都靠不住

    • 这插件仅仅是不够人性化, 弄不好未来还有恶意插件
    • 不懂一切技术细节也没事, 但要备份
    • 对含这几个关键词的功能: 批量, 删除, 同步, 加密, …, 尤其要谨慎

  • 尊重别人的需求

    • 即便是 “解密失败后文件立即自毁” 这种小众需求, 说不定也有人需要
    • 何况这插件并未让文件自毁, 也明确提示了输错密钥的后果
    • 但我相信楼主是为让后人别再吃同样的亏, 而发的这个帖子, 感谢楼主的心意

  • 插件作者是用心写了提示的, 但对不了解加密知识的用户, 这插件还是太难用了…

  • 如果楼主明确记得自己每个操作步骤, 觉得实在还是想要恢复数据, 我乐意尽量帮忙试试

    • 但老实说, 我可能搞不定, 楼主别太指望, 很可能费半天劲也不行
4 个赞
7

写的太好了，对开发者来说，用户永远是靠不住的，对用户来说，软件永远是靠不住的，自己永远是安全的第一责任人。

开发领域有个不成文规则，就是永远不要相信别人的代码，永远不要相信客户端， 验证一切， 假设失败， 边界检查。

我觉得对用户也一样，使用任何软件前，测试无误后再使用，尤其是重要文件，但无论如何，备份永远是最重要的，除非你的数据不重要。一个可靠的备份应当遵循数据备份321原则。

2 个赞