為什麼 Shamir 秘密共享首選二進制擴展欄位？
眾所周知，Shamir 的秘密共享適用於任何有限域，但我不明白為什麼首選二進制擴展域？
只是為kodlu 的出色答案添加更多細節：
使用Shamir在有限域上的秘密共享來共享一些秘密數據 $ \mathrm{GF}(k) $ ，您首先需要將該數據編碼為 $ m ≥ 1 $ 欄位的元素（自然表示為整數，範圍從 $ 0 $ 至 $ k-1 $ )，並且還分配您想要生成欄位的不同非零元素的每個共享作為共享 ID（即 $ x $ 計算共享生成多項式以生成共享的座標）。
然後，您應用共享生成過程，這將為您提供多個共享，每個共享包括 $ m $ 領域元素 $ \mathrm{GF}(k) $ （加上共享 ID）。通過建構，這些份額是均勻分佈的，並且 $ t-1 $ 明智的獨立，在哪裡 $ t $ 是方案的重建門檻值參數，這意味著任何子集 $ s < t $ 的股份與 $ s $ 序列 $ m $ 場元素獨立均勻隨機選擇。特別是，作為一個弱推論，構成股份的所有欄位元素必然均勻分佈在 $ 0 $ 和 $ k-1 $ ， 包括的。
現在，假設您要共享的秘密數據是二進制的，並且編碼為一串 $ n $ 位。如果您碰巧使用的是二進製欄位，那麼 $ k = 2^b $ （而如果 $ n $ 是的倍數 $ b $ )，然後將秘密映射到欄位元素序列非常簡單：只需將 $ n $ -位串入 $ m = \frac nb $ 件 $ b $ 位，每個位自然映射到一個欄位元素。而且由於每一個元素 $ \mathrm{GF}(2^b) $ 也明確地映射到一個字元串 $ b $ 位，您的股份也可以表示為 $ n $ -bit 位串（加上共享 ID）只需連接（二進製表示）每個共享中的欄位元素。
（如果數據長度 $ n $ 是可變的，不一定是的整數倍 $ b $ ，您可能需要在共享之前應用一些填充以明確指示其長度，但這仍然只是一個小麻煩。如果您的數據被編碼為 8 位字節，並且您不需要超過 255 個共享，那麼您可以使用 $ \mathrm{GF}(2^8) $ 並跳過填充。）
但是，如果您不想使用二進製欄位怎麼辦？然後你有幾個選擇：
- 選擇最大的 $ b $ 這樣 $ 2^b < k $ , 將數據拆分為 $ b $ -bit 片段，將它們映射到欄位元素並共享它們。這樣做的主要缺點是股票中的隨機欄位元素不適合 $ b $ 位（因為 $ 2^b < k $ )，因此您需要使用 $ b+1 $ 每個位，至少浪費 $ m $ 每股比特。（共享後的可變長度編碼在這裡無濟於事，因為您無法壓縮均勻的隨機數據。共享前的可變長度編碼是不安全的，因為那樣您的共享長度會洩露有關秘密的資訊。）
你也不能同時安排 $ b $ 和 $ b+1 $ 方便的“圓形”值，例如 8、16、32、64、128 或 256，這意味著您的數據片段或共享片段將不可避免地具有尷尬的長度。例如，假設您想共享 256 位加密密鑰；你可以選擇 $ b = 256 $ ，在這種情況下，您的共享將是 257 位長（並且，如果您想使用素數欄位，則需要以 257 位素數為模進行計算），或者 $ b = 255 $ ，在這種情況下，您需要將密鑰拆分為兩個欄位元素，從而產生 512 位共享。或者你可以使用，比如說， $ b = 32 $ （比如說，素數場 $ \mathrm{GF}(2^{32}+15) $ ，使用 64 位算術有點尷尬，但並非不可能，特別是如果您不需要恆定時間執行）並最終得到 $ 33 \times 8 = 264 $ 經過一些洗牌後的比特股，這可能是一個不錯的中間立場。 2. 使用從二進製到基的通用基數轉換 $ k $ 以最佳方式編碼您的數據（即解釋 $ n $ 位二進制數據作為一個數字 $ 0 $ 至 $ 2^n-1 $ ，然後以基數表示該數字 $ k $ )，以及從基數進行的逆基數轉換 $ k $ 將共享轉換回二進制。你仍然會浪費一些位，所以你的份額會比數據長，但只是一個恆定的數量。不利的一面是基數轉換比簡單的位改組更慢且實現起來更複雜。此外，如果您的秘密長度不固定，您幾乎肯定需要某種填充方案。（並確保始終使用 $ m = \lceil n \log_k 2 \rceil $ ，即使您的秘密值適合較少的基數 $ k $ 數字，以避免共享長度洩漏有關秘密的資訊。）
現在，這些複雜性都不是不可克服的，但它們確實使實現複雜化並使共享編碼效率降低。相比之下，即使您必須實施 $ \mathrm{GF}(2^b) $ 自己從頭算術，使用二進製欄位仍然更簡單。