restkhz 最近的时间轴更新
restkhz
ONLINE

restkhz

V2EX 第 435565 号会员,加入于 2019-08-13 09:09:56 +08:00
今日活跃度排名 10748
restkhz 最近回复了
或许你可以参考 Luhn 算法,身份证校验算法之类的,搞个 mod12 。
还有如果你能加一位号码(考虑到还有星号井号),能多携带\log_2 12 大概 3.6bits 的信息。所以你能做的远超过只是加一个奇偶校验 bit 。从信息论角度,理想情况下最好可以做到 100%-2^(3.6)%,就是多一 bit 能校验一半信息,大概 91.7%的查错率。

这大概是一个历史路径依赖的问题,一开始是和接线员说你找哪里的谁谁谁就好,后来开始用了自动交换机后才开始用号码。
我在博物馆看过那个巨大的貌似叫步进电话交换机的玩意儿,那个时代没有芯片。你拨一个数字,后面那个巨大的机器里面就咔嚓咔嚓地转。
仅仅只是打个电话自动接线就已经非常不容易了...要是让它搞个内存,存你拨的号然后再跑校验算法就太难为他了。
后来电话交换机也数字化了,能玩校验算法了。但是电话号码早就开始全球化了...这个时候就不好升级了。

或许我们对芯片的存在习以为常了
19 天前
回复了 soberzml 创建的主题 游戏 射击小游戏, 上瘾到停不下来😇
海星。650 分,打赢了?如果可以升级武器就好了。
正好这两天在玩。

1-3b 小模型:
LLAMA 的中文不够好,这种尺寸甚至有时候中文语法会出问题,完全不推荐。
Gemma-2-2b 还算正常,智商不咋高,但是能用。
千问 3b 值得一试。Qwen 有一个 0.5b 模型,跑起来没问题,但是没啥用。
其实这种 3b 以下的模型都不算特别实用。我在手机上运行过 llama 那个,卡,非常卡。
简而言之,这个等级的模型我目前没找到什么特别好的用处。可能一些非常简单又机械的任务可以用吧。

PC 能跑的:
我用的 Gemma-2-9b 。有 GPT-3.5 的感觉,但是逊于 GPT-3.5 。我的机器配置不好,在 CPU 中跑的,9b 跑起来不快。大概 3 token/s 这样,但是能用!
DeepSeek R-1 蒸馏那些 7-8b 的模型就比较痛苦。因为经常一言不合开始推理,一推理就要推理一两分钟,给出的结果还是错的。完全不推荐弱 GPU 的 PC 跑。
Llama 3 中文依然不好。我做的测试中,只要用中文,智商就低一个档次。英文感觉还行。

云端:
R-1 在云端跑大一些的模型就量变引起质变了。30B 左右那个等级加上烧钱的配置才有用处。感觉接近 o1-mini 但成本真的高。
Gemma-2-9b 在云端能流畅跑,成本高,而且 token 限制问题,不如你一个好一些的 PC 本地跑一个量化模型了。
Gemma-2-27b 终于能流畅跑,但是质量基本就是 GPT-3.5-turbo ,没必要。


Msty 在我电脑上默认下载的是 Gemma-2b 。可以在网上搜索和总结,效果惊人的还行,速度快,质量算能用。

综上,PC 上 Gemma2 2b 或 9b ,推荐。看你配置了。
手机如果你性能够好,如果 Gemma2 2b 能跑就选择这个。

有条件的话,用 lmstudio 都跑跑。
我来暴论几句。

这个问题主要取决于游戏开发怎么做的了。
可能种子才是更加关键的问题。不管你是普通 PRNG 还是 CSPRNG 都不可能真正扔一个随机数出来,必须要一个种子。问题就在这个种子这里。

操作系统一般都有一个熵池,直接从这里获取种子是最好的。
从服务器熵池生成一个随机数并且确定结果,客户端放动画,PRNG 一次一种子,这种场景是安全的。

首先客户端。
客户端那里没有安全性可言。但是对于很多游戏大量用随机的时候基本都是客户端获取。比如你打怪随机伤害,暴击的随机。至于抽卡,取决于开发怎么想的。理论上,如果你能控制比如/dev/urandom ,逆向出算法,是可以控制抽卡等结果的。但是讲道理哦,你都能做到这些了,为什么不直接修改游戏本身...直接劫持函数或者改包改存档...

服务器上用时间做种子呢?即便在服务器上这东西也不安全。有一个教科书级别的案例就是有某个 PHPbbs 的密码找回链接用的 md5(时间戳)。时间戳有多少可能呢?反正就那几种可能暴力一下就行了。一旦算法被研究出点眉目就容易出事。

好的,排除这些情况。回到楼主的问题。。

服务器生成,种子来源可靠且不可知,算法是普通 PRNG ,但是种子一直被重用,其他因素没有不太可控的,抽卡算法是可知的,那么这样我们可以通过 PRNG 的结果推算种子,的确有可能做到预测结果。如果不只是抽卡,还可以押东西,考虑赔率,那么我们就能“控制”一些东西了。

如果服务器用的是精确到毫秒的那种时间做种子,那么就像抛硬币,只要你抛够多也能有连续 100 次正面一样。如果可以预测,即便做不到精确控制时间,假设网络延迟波动不大,我们依旧能有效找到“胜率”更高的一小段时间。确保服务器在那段时间处理请求就好了。这种情况就算 CSPRNG 也没用。种子得要当密钥看。种子泄漏了不管你是不是密码学伪随机都不会安全。

上面 mc 的例子我猜测,瞎猜,是可以通过强行刷新种子并且种子可知,结果可预测才做到控制。
不好意思暴论太多了。
我大概在十年前玩过这类东西,那会还在中学,穷得很。
当时手头有一个树莓派,于是当时直接在 tb 上搞了一个 pn532 模块,买就送白卡,非常便宜。
直接 GPIO 插上,编译 libnfc 和 mfoc ,mfoc 是...呃...“恢复密钥”的工具。
你想要白卡直接搜 m1 卡,整活的话你可能要那种能改 uid 的卡。uid 卡贵一点。直接搜 uid 白卡就有。

还有一个 Android APP 你可能用得到,这个可以读写 M1 卡,还会“尝试用出厂默认密钥”读卡。要求不高的话这个工具能应付绝大多数场景了。
https://f-droid.org/packages/de.syss.MifareClassicTool/
121 天前
回复了 anivie 创建的主题 Linux kde 美化问题
我不得不说...

我自己就是 Manjaro+KDE 。用了好多年了。一个有 1050N 卡的笔记本。
第一天的时候刚装 Manjaro 直接不能开机. 最后要改内核引导参数。和 ACPI ,N 卡什么毛病有关。
而后想双显卡,经常出问题。卡顿,画面撕裂。后来直接全部 GPU 渲染,
不记得后面又有什么问题了,反正一番折腾再接下来就累了,直接 mhwd 默认 video-hybrid-intel-nvidia-prime 了。
但是默认配置也一直有问题。什么问题呢?

1. KDEconnect 或者什么东西弹出提示后有概率 KDE 卡死。弹窗不消失,工具栏,菜单无响应。
2. Alt+Tab 后界面直接卡死,卡到崩溃,等待几秒中然后 plasma 自己会重启。
3. 任何 CPU 渲染的界面都低帧率。弹个开始菜单卡成 PPT 。

这些问题困扰了我两年,甚至有时候弹窗卡住我就按 Alt+Tab 同时触发 Bug1 和 2 直接卡死让 plasma 快捷重启。试着解决无数遍,一直没啥效果...

直到今天,
楼主你发了这个帖子,我为了看看你说的 kvantum 全面升级了一下系统。
然后上面这个困扰我两年的问题莫名其妙的好了,但是 Chrome 莫名其妙卡得很,打开硬件加速就好了,跑起来一点问题没有。之前不开硬件加速是因为开硬件加速 Chrome 会崩溃....

额,谢谢楼主!...

顺便一说,我觉得 Manjaro KDE 默认的配置稍稍调调也很不错啊。
不好意思,没仔细审题,一次一密码,给上上下下都道个歉,想删除的时候不小心发出来了。尤其是给 @Citrus 道个歉,我没仔细审题。
你提醒我了,你说的对。送一个感谢表示诚意。

感觉怪怪的,想了一会,没想出有啥问题。
不安全,某些情况请千万不要这么做。你的理解大致是正确的,但是尽可能不要固定 IV 。

赞同 @liuidetmks

AES 归 AES ,但是你的加密模式是什么?楼主没有说。
比如,在上面说的 OFB 和 CTR 模式等等情况下,IV 重用并且密码重用的情况下基本就完蛋了。
比如 CTR ,你只需要知道你的明文去和密文 XOR 一下你就知道密码流了。未来的加密形同虚设。
在 CBC 模式虽然不会被直接破解,但是密文相同,破坏了语义安全。有些场景可以接受。

我简单介绍一下一些概念吧,完美安全和语义安全。
完美安全性就是密文本身不会透露任何明文信息。这个太难了。根据信息论,你需要随机密钥+密钥长度至少有明文那么长才能做到。这个时候你的熵就高的足以用来混淆任何一个明文 bit 。
所以楼上 @Citrus 其实说的不完全正确。因为你密码长度只要小了就是不行。不是说会暴力破解,单纯就是熵不够。
你说的严格一次一密,你是指每个 block 都一密码还是完全参照已有的 AES 模式呢?如果你能做到前者,恭喜你,但是直接换成 XOR 玩 OTP 可能更好。做到后者,比如 CBC 模式中,密码随机 IV 固定依旧做不到语义安全。
做到这个太难了。密钥生成,传输,都是问题。

于是人们退而求其次,密文可能会暴露明文信息,但无法被有效利用。这个就是语义安全了。
保存和更新密码的成本太高了。默认密码就会重用。设计的时候也是这么设计的。

这个时候引入 IV 你的确可以理解为增加信息熵,增加密文随机性。某种意义上来说 IV 解决了密码重用的问题(密码学角度的问题)
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2712 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 12ms · UTC 14:26 · PVG 22:26 · LAX 07:26 · JFK 10:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.