雜湊座標（後端），客戶端（前端）不知道座標，但能夠猜測它們
所以我有一組座標，我將使用 SHA256 的隨機鹽對這些座標進行雜湊處理。座標範圍為 0,100。
salt = abc [1, 5] = "sZv6eqPT9bqGiXbjvO8yrb4wuFjl0Z1CwSHdnIgGqEI=" [3, 4] = "8XgDJ/rrDELExVflBfDOLjqV5SB//8urxN5I6hxK9Mo=" [6, 3] = "FTzCfctBaBKp/wmopgMw7YFRpo1z2p6/IdHVujFliGs=" [1, 6] = "t2WE+ba8pt0ZEo0uW3uQH9FpI94tPVaICbctcl0YPtU=" [6, 3] = "FTzCfctBaBKp/wmopgMw7YFRpo1z2p6/IdHVujFliGs="輸入格式為
"{x},{y}".Pastebin 和 C# 程式碼我用來生成這個例子：https ://pastebin.com/yyMiYApc
所以我們有一個後端，我們使用剛剛生成的鹽生成雜湊座標列表。這個想法是將散列座標和鹽發送到前端。因此他們可以使用相同的算法驗證正確的座標。如果前端生成的雜湊與後端的任何雜湊相似，則座標是正確的。他們有 20 次嘗試從前端猜測所有座標。這個想法是前端會用他們的座標和他們的假設呼叫後端，然後後端會驗證他們的假設並將其保存在數據庫中。如果他們提供錯誤的輸入，我們會因為作弊而禁止/打擊使用者。
我們正在創建一個有競爭力的猜謎遊戲，我們不能讓後端的 500 毫秒延遲成為問題，這就是為什麼我們讓前端做出假設並讓後端做出實際決定的原因。基本上是為了消除 UI 中的輸入延遲。
這是一個可靠的計劃，直到我們忘記了任何客戶在驗證了前端的座標後都可以決定不呼叫後端。從而使最大嘗試次數變得多餘。例如，任何客戶端都可以暴力破解所有 10,000 個可能的座標，並檢查其中 5 個是正確的座標。然後在後端呼叫verify 5x 並贏得比賽。
我們為這款遊戲提供了真正的獎品，並希望讓作弊成為不可能，同時消除呼叫後端驗證您的答案的延遲。
我絕不是密碼學專家。密碼學有什麼方法可以幫助我們嗎？如果是的話，你能指出我們正確的方向嗎？如果這個問題不能完全解決，我們怎麼能讓客戶很難作弊呢？
隨意編輯此問題，以便密碼學專家更好地理解它！
編輯1：
現在將鹽發送到前端的原因是因為前端需要知道它們何時有正確的座標。所以，就像我之前解釋的那樣。沒有時間等待後端給出回饋，因為那將是太多的輸入延遲。
每當有人猜出座標時，他們應該立即知道這一點。而不是在遊戲結束時。
您不應該將鹽發送到前端。僅發送雜湊。在“遊戲”完成後，例如，在前端完成您指定的 20 次嘗試後，您應該給出正確答案和鹽。因此，每個參與者都可以檢查您在開始時提供的雜湊是否真的與消息和鹽相匹配。
SHA-256 的加密屬性保證您不能否認正確的答案，因為沒有簡單的方法可以找到產生相同雜湊的另一條消息（在您的情況下為座標）和另一個鹽。在您的範例中，如果您發布雜湊 sZv6eqPT9bqGiXbjvO8yrb4wuFjl0Z1CwSHdnIgGqEI=，那麼每個人都可以確定您找不到任何其他鹽和任何其他產生相同雜湊的消息（座標）。
如果你有客戶端有效的驗證和一個小的可能性空間，它可能是蠻力的。您必須至少更改其中一項：
- 沒有客戶端驗證。
- 更大的可能性空間
- 客戶端驗證效率低下（例如，故意使用慢速雜湊）
您可能會破壞驗證，因此其中一些發生在客戶端，以提供不准確的快速回饋，但仍需要伺服器進行全面驗證。我不清楚為什麼伺服器延遲很重要？如果是網路延遲，您可能需要更近的伺服器並努力減少延遲。