密码学得不好,请问这种简单用户 id 加密模式的安全性有多大问题?

2023-10-09 08:36:32 +08:00
 lithbitren

真实用户 id 是递增数字(可能随机递增),但是不想直接暴露给用户,于是想加密成固定长度的且可供人类阅读的串。

于是我就简单设计一个加密算法,根据对原始数字串进行简单的映射、移位、异或、置换,具体的参数由密钥来确定,简单两个小时写完没有优化,单线程加密百万次大约 650ms ,解密百万次大约 300ms 。

安全性肯定比不上任何一个叫得出名字的非古典加密算法,不过我密码学学得不好,让我自己反推用户 id 感觉毫无头绪。

下面是 100 个连续数字生产的密文 id (假设在某个时段用某种手段注册到了连续的 100 个 id ),所以我自制的这个加密算法有多大可能被简单破解。

[8137831387705, 8766632441404, 8910104411709, 8643189995064, 8062272707134, 8062272707109, 8360588849722, 8436168501822, 8755222343230, 9087172922277, 8146503885753, 8738860500924, 8884484149181, 8651874944952, 8034436934590, 8034436934565, 8334968587194, 8444840885182, 8729602097086, 9089977697445, 8149308546233, 8739450564796, 8882923452605, 8652532248760, 8035090949310, 8035090949285, 8333411040442, 8445494768830, 8728044791998, 8838268586533, 8138117587513, 8764834072124, 8910454312509, 8643488777784, 8060407228990, 8060407228965, 8358794412602, 8436451310142, 8755575668286, 9082675589029, 8142023198649, 8770870401980, 8879932285885, 8645246917560, 8066442497982, 8066442497957, 8330420922298, 8440339357630, 8725054428094, 9083195984549, 8142526685881, 8769180387004, 8880441020093, 8647902201528, 8064820521662, 8064820521637, 8328776925882, 8440864864958, 8725558050494, 9090802285605, 8150149895225, 8742490777660, 8877326544957, 8651196753976, 8038067215422, 8038067215397, 8327844541498, 8439881083966, 8728920743998, 9082598946597, 8141879447353, 8770726765372, 8879859837757, 8645136704312, 8066366904126, 8066366904101, 8330310725434, 8440266893118, 8724944362302, 8837958882213, 8137841437625, 8764524236732, 8910110005181, 8643179073464, 8062245008318, 8062245008293, 8360632191930, 8436140540862, 8755265947582, 8838197468709, 8138063377977, 8764762950204, 8910332072509, 8643434433080, 8060335193662, 8060335193637, 8358673225274, 8436383583806, 8755454198334, 8837982374533]

7220 次点击
所在节点    信息安全
82 条回复
tool2d
2023-10-09 11:18:11 +08:00
@lithbitren 这种算法都是放服务器上运行的,你多试几次就直接封 IP 了,怎么可能爆破。

对任何加密算法来说,密钥都很重要。
x1aoYao
2023-10-09 11:20:48 +08:00
@lithbitren 除去首位,楼上也有提到相邻差值很多 25 的。你如果不加盐,只是固定密钥的话,加异或移位的轮次效果很差。我提到把盐的 hash 得到的 int64 用来异或,就是为了密文除了与原文与密钥相关,还和一个随机数有关。而这个随机数是很难猜的,随机数的 hash 也足够随机。你解密的先得到盐,然后再 hash ,最后就可以得到原文了。
最后即使原文再相近,得到密文和随机乱码差不多了。
x1aoYao
2023-10-09 11:26:25 +08:00
@lithbitren 虽然随机数(盐)和它的 hash 实际有关联,但你后续还有简单的移位映射等,所以看起来就是一个 int128 随机数异或原文 int64(看起来) 当然 hash 函数要足够好(其实就是为了近似加密...
sunmlight
2023-10-09 11:27:41 +08:00
有现成的方案你不用, 非要自己搞些“小聪明”
churchmice
2023-10-09 11:28:26 +08:00
闭门造轮子
lithbitren
2023-10-09 11:33:55 +08:00
@tool2d 不排除其用多个 ip 或者找到某个漏洞,在短时间内多次尝试,所以我主楼给出连续 100 个算是比较多了,其实正常来说应该拿不到这么多 id ,但就是这 100 个数据也被发现出规律,尽管要进一步确认规律也不是那么容易的。
lithbitren
2023-10-09 11:37:22 +08:00
@x1aoYao 不太容易,我用的映射表是 1000 对 1000 的,随机生成,由密钥做成的随机种子(各个过程中都有盐),但我发现主要问题还是+1 的情况下改变位数太少,这些个基本操作还得再重复很多次可能才能消除掉肉眼规律。
chevalier
2023-10-09 11:50:01 +08:00
说个题外话,这种生成的 ID ,对数据库主键非常不友好,数据库写入压力会大很多
lithbitren
2023-10-09 11:54:56 +08:00
@chevalier 其实可以数据库主键递增,取出的时候计算出密文 id ,发送给前端的数据显示的是密文 id ,同时后端可以通过前端传回的密文 id 找到其他用户的真实主键 id ,全程全数字,压力比一些字符串 id 方案要小。
virusdefender
2023-10-09 11:59:14 +08:00
搞的太复杂了,没必要,用户表加个字段,保存另外一个随机 id 就好了。。。
lithbitren
2023-10-09 12:01:41 +08:00
随机 id 是可以考虑的,不过主流数据库随机 id 的存取性能显然也达不到秒内百万次。
PVXLL
2023-10-09 12:02:33 +08:00
民科就喜欢写这些东西,闭门造车的东西安全吗,一定不安全。这种东西还用担心性能,随便优化下 IO 操作时间就补回来了吧
lithbitren
2023-10-09 12:11:38 +08:00
一般对称加密算法对大数据块的加密性能比较好,但这种微型级别的数据的加密时间却也是毫秒级的,存取计算个用户名都要占用毫秒时间,太占用 cpu 了,不如不加密,也不如随机 id 。
julyclyde
2023-10-09 12:28:01 +08:00
hash 难道不是明显错误的答案吗?
无数输入产生少量输出,有碰撞的啊!
nothingistrue
2023-10-09 12:32:52 +08:00
自增用户 ID ,除了暴露用户量,还能暴露啥。如果它本来就是跟用户原本信息,注册时空信息都无关联,只是人工关联上去的一串数字,那么它的信息量就是个代号。这时候任何静态加密,都是画蛇添足而已,不论加密多少遍,它都可以直接拿出来当用户的代号。弄个雪花 ID 或者 HASH ,将其外围统计信息隐藏掉,并方便存储优化即可。

你要真相搞隐藏用户 ID 的安全控制,那应该搞动态加密,即不同时空下的密文不同,还都能通过私钥推导到同一个 ID 。
geelaw
2023-10-09 12:35:55 +08:00
要考虑算法是否安全,第一步是理解什么叫做“安全”,对于用户 ID 这种对象,我不了解是否有标准的安全定义,所以无法谈论安全性。
CRVV
2023-10-09 12:40:33 +08:00
加密短的数据不可能耗时达到毫秒级
openssl speed -evp aes-128-gcm -bytes 16
在我的机器上只需要 16ns ,这个测试的结果显然没有包含访问主内存的时间(已经在一级缓存上)

自创的加密算法安全不安全?这个问题有标准答案,不安全
在某个项目上是不是适用? 1 楼也已经答了,对没有价值的数据适用
有多大可能被破解?这个得给钱,不然不可能有高手帮你评估破解难度
tool2d
2023-10-09 12:52:15 +08:00
@julyclyde 你看我 20 楼的链接,“A perfect hash function is one that is collision-free.”,perfect 就代表了无碰撞。

当然这种 hash 都会限定输入的大小,一般都是输入多少位,输出就多少位。无限大小的输入,肯定有碰撞。
mightybruce
2023-10-09 13:02:46 +08:00
从你说出的进行简单的映射、移位、异 r 或、置换, 那么这个加密强度还不如 DES 。
AES 一轮加密就已经包含这些了,并比这个复杂,用到了非线性模块。

如果你遇到一个黑客专家或密码学高手,的确是很容易被破解, 你算法是建立在密码算法没人知晓的情况下,
参考二战的恩尼格玛密码机被破译,没有什么绝对安全的加密算法, 在密码学 Oracle 看来,时间和计算成本足够下都能破解。
如果有个人愿意花大价钱要搞你,你这个经不起推敲。我就不谈现代密码学分析如差分密码分析


另外题主说的不是 hash, 用密钥的对称加密。
xingguang
2023-10-09 13:41:18 +08:00
如果是自己项目,那么都可以,如果是公司项目,你这个算法导致出了问题那么你要背锅的,如果用市面上有的那么这个锅可以无限小
另外,其实感觉你不是寻求建议的,而是找认同的,看下来大部分都不太赞同你用自己写的算法,但是你的论点一直在于自己的快,市面上的太慢

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/980076

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX