ysmood

ysmood

V2EX 第 39678 号会员,加入于 2013-05-25 17:38:08 +08:00
今日活跃度排名 8742
根据 ysmood 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
ysmood 最近回复了
45 天前
回复了 NerdHND 创建的主题 React Zustand 的文件组织?
我也是头疼 zustand 的文件组织和冗长代码,于是最近自己写了个库 stalo 。我写了个 todo app 用来演示如何将一个 store 分割成逻辑隔离的多个文件: https://github.com/ysmood/stalo/tree/main/examples/TodoApp

从目前我自己的使用来看,各项指标都由于 zustand ,我甚至用 stalo 写了个 devtools 来 debug stalo 自己: https://stalo-examples.vercel.app/examples/Devtools.tsx
178 天前
回复了 0o0O0o0O0o 创建的主题 分享创造 vaultwarden 备份思路之再也不改版
@kuanat 可以试试这个,比 gpg 更简单方便 https://github.com/ysmood/whisper
@chaoschick 这种工具之所以存在就是因为现有的很多系统功能不全,且不愿意花时间改进,比如 V2EX 就没法私信,这个时候有这种工具就会方便点,你如果不用类似工具,请问 v 站里两个陌生人在不暴露自己隐私的情况下如何交换邮箱互加好友?你可能可以,但是会很麻烦
@chaoschick 你可以看看 age 这个工具 https://github.com/FiloSottile/age 被非常多的库依赖了,你可能不太能理解它的用途,但事实上用的人非常多。
> 第二个问题,似乎你没有理解第一个攻击例子的场景:A 要和 B 说话,B 选择去听任何人的话,M 达成的效果是 M 不知道 A 想说什么,但是让 B 以为 M 说了 A 本来要说的话。B 是用 M 的公钥验证的。

你都不在乎谁发给信息了如何防止中间人攻击?

> 通行的做法是归约,你的算法可以看作某种安全性的 KEM 和 CPA 安全的私钥加密和签名的复合,无法推出第一个例子下的安全性。

就和你说的一样,这不是 whisper 想要解决的问题,这更像是 ssl 之类的需要考虑的问题。使用 whisper 的人大大概率不会考虑中间人攻击的问题,所以 sign 是可选的否则我就设置成必选的了。
@Senorsen #22

> 谢谢回答,不过我的问题在于,只使用“加密”是不需要私钥的,只需要拉取 GitHub 上目标用户的公钥,因此无条件启动 agent 的行为比较怪。

多谢,这是个很好的建议,我把它改成只有需要的时候才启动好了。
加 sign 或者解密的时候都需要 passphrase ,非常常用。我建议是即使是发送的时候也加个 sign ,更安全。
@geelaw #25

> 但是这会导致没有选择超过 128 位密钥的意义,限制了最大安全性。

openssl 默认用的 128bit ,在 whisper 的使用场景已经够安全了,因为这个 aes key 只会被使用一次就扔了。我加了个选项: https://github.com/ysmood/whisper/blob/86d93ffbb3897d1739664da5597f6b85d1045be4/lib/piper/encodings.go#L74-L75

> 第二个问题,对密文签名只能保证密文“被谁同意”,不能保证明文来自于谁,也不能保证密文在加密结束之后没有被“有意义地修改过”,后者是选择密文安全性的要求。

whisper 没有这个问题,readme 里已经说明了 sign 验证需要显示声明发件人的 github id 用以验证,否则你就不在乎被篡改。你不可能再签名的,验证会失败。

> 除非收信人只收取某个特定的人(以签名所用的公钥识别)的信息(因此 M 重新签名不会被接受),否则上述场景可以成立。

和上一个问题一样。

> 但如果收信人只收取特定的人的信息,则没必要每次通信都用公钥加密。

这也不是安全问题,只是某种大部分人不在乎的性能优化,whisper 的使用场景是单次的无状态通信。
346 天前
回复了 LonnyWong 创建的主题 程序员 我把开源 README 又改成英文了
还是依赖了 ssh-agent 服务吗?也就是如果没装 ssh 就没法用 agent 吗?
@geelaw #24

> 你的第一段回复表明确实弄混了块长度和密钥长度,AES 的块长度永远是 128 位,密钥有三种长度。不存在“选择”块长度这种操作,因为没的可选。

我意思是保证不论使用什么长度的 secret ,最终都是使用 AES-128 ,这是 golang 的标准库规定的用法。抱歉没有很专业的表达我的意思,我这里并不在乎块的长度。所以我这个操作又安全风险吗?


> 第二段回复表明没理解什么是选择密文安全性。把公钥加密和 AES 以 OFB 模式(不是选择密文安全)结合时当然不可能期待选择密文安全性。

抱歉我理解错了你的意思,你意思就是信息可以被篡改吧?这个攻击又不可以破解具体内容。whisper 不是提供了 sign 吗,文档里最后有提到 sign 的用法,如果你觉得你的数据有被中间人篡改的风险,用 whisper 的 -s 参数就行了。
@Senorsen 感谢试用!

> ssh 密钥确实也是个问题

关于选哪个 ssh 密匙一般不存在问题,大部分人机子里都有。而且可以加冒号选择某个 ssh pub key ,比如 "@ysmood:abc"

> 这密文还挺长的

密文已经很短了,你看 gpg 生成的比这可能长几倍。同类工具这个应该是最短的。

> 请教下为啥需要一个 background agent ?

因为 private key 通常是一个文件,任何系统里的 app 都可以读取到这个文件,这很不安全。所以一般都会用一个 passphrase 加密这个 private key ,只有用的时候才解密到内存里使用,这样任何系统里的 app 都没法获取真正的 private key 。但这会引入一个新问题,每次都输入 passphrase 非常麻烦,所以一般加密工具都会提供一个 agent 来缓存 passphrase 到内存,比如 ssh-agent ,这样只有重启电脑的时候才需要再输入一次。

这是一个非常通用的技巧,Apple 的 Touch ID 也是这样的,只不过它用了一个专用 chip 来缓存,掉电了就得重新输入 passcode 。
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2446 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 07:09 · PVG 15:09 · LAX 23:09 · JFK 02:09
Developed with CodeLauncher
♥ Do have faith in what you're doing.