Re: [情報] 「手遊虛擬轉蛋」糾紛多 綠委籲修法

[mikapauli (桜花)]

感覺再說下去會越來越與C洽無關，不過推文這麼多我再稍微延伸一下。

上一篇文的比喻雖然比較好懂(?)，但就像推文說的，

每次都要產生一對加解密用的金鑰而且用完就丟非常不經濟。

因此實際上遊戲有在用的密文驗證(不一定是轉蛋)是公鑰驗證。


流程差別如下

私鑰驗證：

加密：私鑰／解密：私鑰

加密→傳送密文→玩家選擇→傳送解密私鑰→玩家解密密文驗證


公鑰驗證：

加密：公鑰／解密：不需要，通常是無解

約定公鑰→加密→傳送密文→玩家選擇→傳送明文→玩家加密明文驗證密文＝明文＋公鑰

--
オーカの意味は……「繋げる者」
オークはリューン語で繋がりを意味している｡
その変形語がオーカだ｡
桜花｡
願わくば､
人とリューンを繋げる者となるように｡

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.92.30.205
※ 文章網址: https://www.ptt.cc/bbs/C_Chat/M.1500365553.A.4EB.html
推 arthurduh1: 推. 就密碼學的角度, 真的要做到機率公開是可以的.
→ arthurduh1: 但不曉得是不是因為大人的因素, 或根本不被重視,
→ arthurduh1: 一直沒有實現.
→ guesd: 不完全對 資訊安全的基本是你必須要相信某些東西才能繼續
→ guesd: 當伺服器不相信客端 玩家不相信遊戲商 這什麼加密都沒有用
→ guesd: 除非中間再引入公正第三方的驗證程序
→ Golu: 應該說，遊戲中一定會使用訊息加密，只是時機點和資料量差異
→ arthurduh1: 有部分的系統就是拿來處理這種不信任的問題, 能夠
→ arthurduh1: 很大程度地確保廠商無法作弊.
→ Golu: 但抽獎這牽扯到人性的部分，技術只需要保證"玩家無法手動更
→ Golu: 換資料內容"即可
→ Golu: 多做玩家不見得信任，也有的是"不願意信任"，更何況玩家中也
→ Golu: 存在非常態玩家，具抽獎或者競技類的遊戲在設計時多半是基於
→ Golu: "任何玩家都有可能使用作弊工具"的前提去設計
→ arthurduh1: 並不需要公正第三方.
→ arthurduh1: 在適當加密之下, 手動更變資料內容是沒有意義的.
→ Golu: 與其說是"大人的理由"，不如說是營運、時程、開發等要素考量
→ Golu: 下，選擇在某些地方轉移處理成本以加快開發時程
推 arthurduh1: 那就是不被重視的意思XD
→ guesd: 不，這個問題是雙方的，當你把系統設計成廠商無法作弊時
→ Golu: 應該說，在這個領域內受重視的部分和程度不會是在抽抽上
→ guesd: 幾乎同樣也就表示玩家有辦法偷看答案了(在只有2tier的狀況)
→ Golu: 這感覺就像是你跟籃球選手說曲棍球裝的護具能有效減少傷害
→ Golu: 你們籃球員怎麼不試試看
→ Golu: 通常就是被擺個黑人問號吧
推 arthurduh1: 並不能偷看答案, 有個類似的概念是 zero knowledge
→ arthurduh1: proof, 或是找一下用密碼學猜拳, 猜拳基本上就跟
→ arthurduh1: 轉蛋是一樣的, 雙方都不信任對方, 但還是能做到公平.
推 sokayha: 所以關鍵是"非常难找到两个x, y 满足f(x) = f(y)"
→ sokayha: 可以理解
→ sokayha: 因為上一篇時就是在想準備多重密鑰來作弊成任意解
推 arthurduh1: 沒錯, 所有公鑰系統的延伸幾乎都是建立在這種單向函數
→ arthurduh1: 上面, 當然無法完全保證「不能作弊」, 但難度非常高.
→ linzero: 你前一篇看來是可行的。但大概只適用機率選項較少的情況
→ linzero: 比方最低是1%，須準備100個選項。當機率0.1%、0.01%時，
→ linzero: 選項會多到實務界面上設計困難，以及使用者感受不佳
→ linzero: 然後還有個問題是，玩家有辦法額外用程式去抓取比對加密
→ linzero: 情況，還是得相信官方的遊戲程式比對？
推 arthurduh1: 其實這部分都不會有問題哦. 完全可以依照以前轉蛋的
→ arthurduh1: 遊戲體驗, 加個 open source 的程式轉換.
→ arthurduh1: 用這個方法, 10000個選項其實都不算多.
→ arthurduh1: 這個程式轉換的部分純粹是為了遊戲體驗, 使用者去
→ arthurduh1: 竄改不會影響到公平性.
→ arthurduh1: 之後想檢查的玩家再自行檢查就好, 甚至把檢查的部分
→ arthurduh1: 寫進 open source 的部分就能自動進行檢查.
→ arthurduh1: (open source 的部分在 client 端)
→ arthurduh1: 這樣遊玩起來跟以前完全沒有差別~
推 sokayha: 實作大概可以類似
→ sokayha: 伺服端產生此次table，例如0001001020，此為參數A，然後
→ sokayha: 一任意數B，兩者玩家抽前無法知道，然後告訴玩家一個用到
→ sokayha: 兩個輸入參數A和B的標準公式(公鑰)，以及計算結果假設是3
→ sokayha: 41275顯示在抽卡介面底下，等玩家抽完，介面顯示系統剛用
→ sokayha: 到的參數A、B給玩家，玩家就能自行驗證此次抽抽的table(
→ sokayha: 參數A)的確是0001001020
→ arthurduh1: 你應該沒理解錯XD
→ arthurduh1: 然後上面那段我要說的是完全可以讓電腦幫你選擇
→ arthurduh1: 龐大的選項, 反正已經是公平的, 隨機抽一個都行.
→ arthurduh1: 不過你的公鑰弄錯地方了, 那個公式是密碼系統一部份.
→ arthurduh1: 在這個系統應該沒有東西叫公鑰, 但有類似的概念.
→ arthurduh1: 比較像是 341275 那部分
→ arthurduh1: 而且一般來說為了提高可信度, 算出來的不會只有341275
→ arthurduh1: 而會是很長的一串資料(但對電腦來說不長XD
→ arthurduh1: 然後玩家自行驗證的部分可以由 client 端程式自動處理
→ mikapauli: 感謝亞瑟大在我上班時支援OTL
→ mikapauli: 然後其他人說到在client端作弊其實是指，server其實有
→ mikapauli: 偷偷傳一個指令給client的"隨機"器，讓所謂的隨機其實
→ mikapauli: 被server決定的，因而抽到對玩家不利的結果
→ mikapauli: 所謂才說最關鍵的抽選要在client而且要是人為隨機
→ mikapauli: 也就是要玩家自己選，或者至少做選擇的部分要open
→ mikapauli: 玩家也可以自己改
→ Golu: 原PO"或者至少做選擇的部分要open"這段可把行為定義的更詳細
→ Golu: 一點？畢竟在開發者角度來說，這樣的說法就是直接在選擇時
→ Golu: 打開後門功能，對沒有經過特別加密的遊戲要逆工程難度不高，
→ Golu: 而直接開個後門讓別人可以透過選擇的功能access到server是件
→ Golu: 很危險的事情
→ mikapauli: 我是指open source啦，也就是如果不是全部的client端
→ mikapauli: 至少抽選部分的原始碼能檢視，而且在基於電腦沒有真正
→ mikapauli: 隨機的事實,玩家也要能自己修改抽選邏輯(別的隨機器等)
→ mikapauli: 才算完全公平
→ Golu: 以研究或學術性質來說open source是很好啦，但套用在一個都
→ mikapauli: 我覺得還是出現個100x100的格子讓玩家自己點比較有感覺
→ Golu: 想要盡可能防止別人突破自身產品的產業，要提倡open source
→ Golu: 我想還是想想就好，笑笑就好了wwwww
→ mikapauli: 這些包括驗證本來就是除非有規定不然沒人要做的阿XD
→ mikapauli: 不過這類加密驗證在像是連線麻將裡還蠻常見的
→ Golu: 對戰型遊戲加密只是基本
→ Golu: 所以我前面推文才提到，不是不用，是不在轉蛋用
推 Ayukawayen: 這沒有很難 伺服器端先給hash 抽完驗hash就好了
→ Golu: 一般socket用hash去處理就夠用了，不特別想要顯示公平性
→ Golu: 就算丟給玩家看，不信的還是不信wwwwww
→ mikapauli: 這東西還是消保官去看吧
→ mikapauli: 玩個遊戲還要看封包，我是要寫外掛嗎XD
→ Golu: 不然你以為工作室小黑窗是做啥用的wwwww
推 Ayukawayen: 聽說有些真金白銀的賭博程式有在用 hash驗證法
→ mikapauli: 有些常用的hash其實有危險性就是了
→ mikapauli: 不過因為還有逾時不信任，不要像是MD5這種應該就還OK
推 arthurduh1: 之所以說 open source 是因為這部分根本跟公平與否
→ arthurduh1: 無關, 這部分就很像按鍵精靈, 你會去質疑按鍵精靈
→ arthurduh1: 有沒有有可能被使用者更改嗎?
→ arthurduh1: 其實那部分不 open source 也沒關係, 有心的玩家檢查
→ arthurduh1: 封包就好了, 因為要提倡公平, 這部分封包必須大家都能
→ arthurduh1: 讀得懂. 跟提倡 open source 無關, 這重點抓錯了啊XD
→ arthurduh1: 就是一個按鍵精靈, 根本沒啥好保密的
推 Golu: 所以我才不懂為啥這個東西得扯到client的open source 啊wwww
推 arthurduh1: 然後我看了 19:34 的推文, 可能 Golu 你沒有搞懂
→ arthurduh1: 系統的強大之處, 那些怕被破解的論述都比較像私鑰
→ arthurduh1: 型的系統要擔心的事. 公鑰系統是從理論上就斷絕作弊
→ arthurduh1: 的可能性.
→ arthurduh1: 因為就只是一個按鍵精靈, 它要做什麼事公開就好了啊,
→ arthurduh1: 或至少讓人可以簡單的逆向, 這部分就沒啥技術可言.
→ arthurduh1:                                      *沒有搞懂公鑰
→ arthurduh1: 沒公開又會有人來吵說會不會在這裡藏後門, 跟公開機率
→ arthurduh1: 這個終極目標相違背.
推 Golu: 不是喔，我那段不是糾結在公鑰的問題，而是mikapauli到底是
→ Golu: 在說哪個部分，不同領域的某些慣用用詞總會造成誤差
→ Golu: 更後面的回文則是針對mikapauli強調open source這部分覺得很
→ Golu: 無厘頭
→ Golu:                                         ^想問mikapauli
→ mikapauli: 我只是那句太長source打不下去只打了open而已XD
→ Golu: 這也是為啥我後面回文都在針對open source這點，在製作商業
推 arthurduh1: 如果廠商願意採用這套系統, 那代表他們想要宣示
→ Golu: 導向的遊戲，提到遊戲本體open source是很詭異的概念(笑
→ arthurduh1: 他們的機率是完全公正的, 在這個前提下, 把 client 端
→ arthurduh1: 隨機抽取的部分公開是有利無弊
→ arthurduh1: 不需要是本體, 可以做個接口連到這個小程式就好.
→ mikapauli: 我也是覺得不需要open source
→ mikapauli: 就做個100x100格子讓玩家點還更有趣(?
→ arthurduh1: 只需要這個小程式結構是公開的, 遊戲本體你怎麼加密
→ arthurduh1: 都不成問題.
推 sokayha: 那不就還要證明玩家執行的遊戲本體跟open source出來的co
→ sokayha: de是同一套...
→ arthurduh1: 不用, 玩家自己改也沒差.
→ arthurduh1: 理論上就是你這個小程式怎麼改, 公正性都沒影響.
→ arthurduh1: 就很像你不知道答案分布的情況下, 不管用什麼策略
→ arthurduh1: 去回答選擇題, 答對機率都是一樣的.
→ arthurduh1: 這個小程式就是讓電腦幫你選100x100的格子XD
→ Golu: 就我所知實體博弈機台的機率與CODE是會給第三方機構審查的
→ arthurduh1: 這是要讓遊戲體驗不變的情形下需要的小程式, 當然
→ arthurduh1: 如果像 mikapauli 說的想改遊戲體驗, 就是另一回事了
→ mikapauli: sokayha你可以自己編譯然後替換調現有的bin
→ arthurduh1: 這是因為機台不是你的電腦XD 你的電腦你可以自己掌控
→ Golu: 其實arthurduh1後面的概念與說法讓我釐清不少wwww，一開始混
→ Golu: 太多概念在一起讓我覺得"這根本是自己在想爽的吧"wwww
→ arthurduh1: 概念有傳達到很高興 :)
→ Golu:                                     mikapauli混太多觀念
→ Golu: 題外話，七騎士某個常駐的SP抽抽執行介面就類似mikapauli提
→ mikapauli: 我一開始只是想用整盒食玩來比喻機率確證的可行性
→ Golu: 到的樣子，而地城戰旗應該也是符合
→ mikapauli: 提到實際上的運作感覺會偏離板旨XD
推 arthurduh1: 這些介面就是我說的遊戲體驗, 隨機性的底層部分
→ arthurduh1: 只要做好了, 你介面怎麼設計都沒關係