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