Re: [情报] “手游虚拟转蛋”纠纷多 绿委吁修法

楼主: mikapauli (桜花)   2017-07-18 16:12:23
感觉再说下去会越来越与C洽无关,不过推文这么多我再稍微延伸一下。
上一篇文的比喻虽然比较好懂(?),但就像推文说的,
每次都要产生一对加解密用的金钥而且用完就丢非常不经济。
因此实际上游戏有在用的密文验证(不一定是转蛋)是公钥验证。
流程差别如下
私钥验证:
加密:私钥/解密:私钥
加密→传送密文→玩家选择→传送解密私钥→玩家解密密文验证
公钥验证:
加密:公钥/解密:不需要,通常是无解
约定公钥→加密→传送密文→玩家选择→传送明文→玩家加密明文验证密文=明文+公钥
作者: arthurduh1 (arthurduh1)   2017-07-18 16:21:00
推. 就密码学的角度, 真的要做到机率公开是可以的.但不晓得是不是因为大人的因素, 或根本不被重视,一直没有实现.
作者: guesd (海边漂来的香草)   2017-07-18 16:42:00
不完全对 资讯安全的基本是你必须要相信某些东西才能继续当服务器不相信客端 玩家不相信游戏商 这什么加密都没有用除非中间再引入公正第三方的验证程序
作者: Golu (没了戒指的魔王)   2017-07-18 16:44:00
应该说,游戏中一定会使用讯息加密,只是时机点和资料量差异
作者: arthurduh1 (arthurduh1)   2017-07-18 16:44:00
有部分的系统就是拿来处理这种不信任的问题, 能够很大程度地确保厂商无法作弊.
作者: Golu (没了戒指的魔王)   2017-07-18 16:45:00
但抽奖这牵扯到人性的部分,技术只需要保证"玩家无法手动更换资料内容"即可多做玩家不见得信任,也有的是"不愿意信任",更何况玩家中也存在非常态玩家,具抽奖或者竞技类的游戏在设计时多半是基于"任何玩家都有可能使用作弊工具"的前提去设计
作者: arthurduh1 (arthurduh1)   2017-07-18 16:49:00
并不需要公正第三方.在适当加密之下, 手动更变资料内容是没有意义的.
作者: Golu (没了戒指的魔王)   2017-07-18 16:50:00
与其说是"大人的理由",不如说是营运、时程、开发等要素考量下,选择在某些地方转移处理成本以加快开发时程
作者: arthurduh1 (arthurduh1)   2017-07-18 16:52:00
那就是不被重视的意思XD
作者: guesd (海边漂来的香草)   2017-07-18 16:53:00
不,这个问题是双方的,当你把系统设计成厂商无法作弊时
作者: Golu (没了戒指的魔王)   2017-07-18 16:53:00
应该说,在这个领域内受重视的部分和程度不会是在抽抽上
作者: Golu (没了戒指的魔王)   2017-07-18 16:55:00
这感觉就像是你跟篮球选手说曲棍球装的护具能有效减少伤害你们篮球员怎么不试试看通常就是被摆个黑人问号吧
作者: arthurduh1 (arthurduh1)   2017-07-18 16:57:00
并不能偷看答案, 有个类似的概念是 zero knowledgeproof, 或是找一下用密码学猜拳, 猜拳基本上就跟转蛋是一样的, 双方都不信任对方, 但还是能做到公平.
作者: sokayha (sokayha)   2017-07-18 17:04:00
所以关键是"非常难找到两个x, y 满足f(x) = f(y)"可以理解因为上一篇时就是在想准备多重密钥来作弊成任意解
作者: arthurduh1 (arthurduh1)   2017-07-18 17:07:00
没错, 所有公钥系统的延伸几乎都是建立在这种单向函数上面, 当然无法完全保证“不能作弊”, 但难度非常高.
作者: linzero (【林】)   2017-07-18 17:21:00
你前一篇看来是可行的。但大概只适用机率选项较少的情况比方最低是1%,须准备100个选项。当机率0.1%、0.01%时,选项会多到实务界面上设计困难,以及使用者感受不佳然后还有个问题是,玩家有办法额外用程式去抓取比对加密情况,还是得相信官方的游戏程式比对?
作者: arthurduh1 (arthurduh1)   2017-07-18 17:37:00
其实这部分都不会有问题哦. 完全可以依照以前转蛋的游戏体验, 加个 open source 的程式转换.用这个方法, 10000个选项其实都不算多.这个程式转换的部分纯粹是为了游戏体验, 使用者去窜改不会影响到公平性.之后想检查的玩家再自行检查就好, 甚至把检查的部分写进 open source 的部分就能自动进行检查.(open source 的部分在 client 端)这样游玩起来跟以前完全没有差别~
作者: sokayha (sokayha)   2017-07-18 18:02:00
实作大概可以类似伺服端产生此次table,例如0001001020,此为参数A,然后一任意数B,两者玩家抽前无法知道,然后告诉玩家一个用到两个输入参数A和B的标准公式(公钥),以及计算结果假设是341275显示在抽卡接口底下,等玩家抽完,接口显示系统刚用到的参数A、B给玩家,玩家就能自行验证此次抽抽的table(参数A)的确是0001001020
作者: arthurduh1 (arthurduh1)   2017-07-18 18:05:00
你应该没理解错XD然后上面那段我要说的是完全可以让电脑帮你选择庞大的选项, 反正已经是公平的, 随机抽一个都行.不过你的公钥弄错地方了, 那个公式是密码系统一部份.在这个系统应该没有东西叫公钥, 但有类似的概念.比较像是 341275 那部分而且一般来说为了提高可信度, 算出来的不会只有341275而会是很长的一串资料(但对电脑来说不长XD然后玩家自行验证的部分可以由 client 端程式自动处理
楼主: mikapauli (桜花)   2017-07-18 19:01:00
感谢亚瑟大在我上班时支援OTL然后其他人说到在client端作弊其实是指,server其实有偷偷传一个指令给client的"随机"器,让所谓的随机其实被server决定的,因而抽到对玩家不利的结果所谓才说最关键的抽选要在client而且要是人为随机也就是要玩家自己选,或者至少做选择的部分要open玩家也可以自己改
作者: Golu (没了戒指的魔王)   2017-07-18 19:34:00
原PO"或者至少做选择的部分要open"这段可把行为定义的更详细一点?毕竟在开发者角度来说,这样的说法就是直接在选择时打开后门功能,对没有经过特别加密的游戏要逆工程难度不高,而直接开个后门让别人可以透过选择的功能access到server是件很危险的事情
楼主: mikapauli (桜花)   2017-07-18 19:38:00
我是指open source啦,也就是如果不是全部的client端至少抽选部分的原始码能检视,而且在基于电脑没有真正随机的事实,玩家也要能自己修改抽选逻辑(别的随机器等)才算完全公平
作者: Golu (没了戒指的魔王)   2017-07-18 19:44:00
以研究或学术性质来说open source是很好啦,但套用在一个都
楼主: mikapauli (桜花)   2017-07-18 19:44:00
我觉得还是出现个100x100的格子让玩家自己点比较有感觉
作者: Golu (没了戒指的魔王)   2017-07-18 19:45:00
想要尽可能防止别人突破自身产品的产业,要提倡open source我想还是想想就好,笑笑就好了wwwww
楼主: mikapauli (桜花)   2017-07-18 19:49:00
这些包括验证本来就是除非有规定不然没人要做的阿XD不过这类加密验证在像是连线麻将里还蛮常见的
作者: Golu (没了戒指的魔王)   2017-07-18 19:52:00
对战型游戏加密只是基本所以我前面推文才提到,不是不用,是不在转蛋用
作者: Ayukawayen (亚布里艾尔发芽>//<)   2017-07-18 19:52:00
这没有很难 服务器端先给hash 抽完验hash就好了
作者: Golu (没了戒指的魔王)   2017-07-18 19:55:00
一般socket用hash去处理就够用了,不特别想要显示公平性就算丢给玩家看,不信的还是不信wwwwww
楼主: mikapauli (桜花)   2017-07-18 19:59:00
这东西还是消保官去看吧玩个游戏还要看封包,我是要写外挂吗XD
作者: Golu (没了戒指的魔王)   2017-07-18 20:00:00
不然你以为工作室小黑窗是做啥用的wwwww
作者: Ayukawayen (亚布里艾尔发芽>//<)   2017-07-18 20:01:00
听说有些真金白银的赌博程式有在用 hash验证法
楼主: mikapauli (桜花)   2017-07-18 20:05:00
有些常用的hash其实有危险性就是了不过因为还有逾时不信任,不要像是MD5这种应该就还OK
作者: arthurduh1 (arthurduh1)   2017-07-18 20:18:00
之所以说 open source 是因为这部分根本跟公平与否无关, 这部分就很像按键精灵, 你会去质疑按键精灵有没有有可能被使用者更改吗?其实那部分不 open source 也没关系, 有心的玩家检查封包就好了, 因为要提倡公平, 这部分封包必须大家都能读得懂. 跟提倡 open source 无关, 这重点抓错了啊XD就是一个按键精灵, 根本没啥好保密的
作者: Golu (没了戒指的魔王)   2017-07-18 20:28:00
所以我才不懂为啥这个东西得扯到client的open source 啊wwww
作者: arthurduh1 (arthurduh1)   2017-07-18 20:28:00
然后我看了 19:34 的推文, 可能 Golu 你没有搞懂系统的强大之处, 那些怕被破解的论述都比较像私钥型的系统要担心的事. 公钥系统是从理论上就断绝作弊的可能性.因为就只是一个按键精灵, 它要做什么事公开就好了啊,或至少让人可以简单的逆向, 这部分就没啥技术可言.*没有搞懂公钥没公开又会有人来吵说会不会在这里藏后门, 跟公开机率这个终极目标相违背.
作者: Golu (没了戒指的魔王)   2017-07-18 20:33:00
不是喔,我那段不是纠结在公钥的问题,而是mikapauli到底是在说哪个部分,不同领域的某些惯用用词总会造成误差更后面的回文则是针对mikapauli强调open source这部分觉得很无厘头^想问mikapauli
楼主: mikapauli (桜花)   2017-07-18 20:35:00
我只是那句太长source打不下去只打了open而已XD
作者: Golu (没了戒指的魔王)   2017-07-18 20:37:00
这也是为啥我后面回文都在针对open source这点,在制作商业
作者: arthurduh1 (arthurduh1)   2017-07-18 20:37:00
如果厂商愿意采用这套系统, 那代表他们想要宣示
作者: arthurduh1 (arthurduh1)   2017-07-18 20:38:00
他们的机率是完全公正的, 在这个前提下, 把 client 端随机抽取的部分公开是有利无弊不需要是本体, 可以做个接口连到这个小程式就好.
楼主: mikapauli (桜花)   2017-07-18 20:39:00
我也是觉得不需要open source就做个100x100格子让玩家点还更有趣(?
作者: arthurduh1 (arthurduh1)   2017-07-18 20:39:00
只需要这个小程式结构是公开的, 游戏本体你怎么加密都不成问题.
作者: sokayha (sokayha)   2017-07-18 20:40:00
那不就还要证明玩家执行的游戏本体跟open source出来的code是同一套...
作者: arthurduh1 (arthurduh1)   2017-07-18 20:41:00
不用, 玩家自己改也没差.理论上就是你这个小程式怎么改, 公正性都没影响.就很像你不知道答案分布的情况下, 不管用什么策略去回答选择题, 答对机率都是一样的.这个小程式就是让电脑帮你选100x100的格子XD
作者: Golu (没了戒指的魔王)   2017-07-18 20:44:00
就我所知实体博弈机台的机率与CODE是会给第三方机构审查的
作者: arthurduh1 (arthurduh1)   2017-07-18 20:44:00
这是要让游戏体验不变的情形下需要的小程式, 当然如果像 mikapauli 说的想改游戏体验, 就是另一回事了
楼主: mikapauli (桜花)   2017-07-18 20:45:00
sokayha你可以自己编译然后替换调现有的bin
作者: arthurduh1 (arthurduh1)   2017-07-18 20:45:00
这是因为机台不是你的电脑XD 你的电脑你可以自己掌控
作者: Golu (没了戒指的魔王)   2017-07-18 20:45:00
其实arthurduh1后面的概念与说法让我厘清不少wwww,一开始混太多概念在一起让我觉得"这根本是自己在想爽的吧"wwww
作者: arthurduh1 (arthurduh1)   2017-07-18 20:46:00
概念有传达到很高兴 :)
作者: Golu (没了戒指的魔王)   2017-07-18 20:47:00
mikapauli混太多观念题外话,七骑士某个常驻的SP抽抽执行接口就类似mikapauli提
楼主: mikapauli (桜花)   2017-07-18 20:52:00
我一开始只是想用整盒食玩来比喻机率确证的可行性
作者: Golu (没了戒指的魔王)   2017-07-18 20:52:00
到的样子,而地城战旗应该也是符合
楼主: mikapauli (桜花)   2017-07-18 20:53:00
提到实际上的运作感觉会偏离板旨XD
作者: arthurduh1 (arthurduh1)   2017-07-18 20:54:00
这些接口就是我说的游戏体验, 随机性的底层部分只要做好了, 你接口怎么设计都没关系

Links booklink

Contact Us: admin [ a t ] ucptt.com