執行範圍限制承諾失敗？

Question

因爲我必須實現我的論文的一部分（在Java中）引Boudot的紙成龍，弗蘭克爾Tsiounis範圍有界的承諾協議Efficient Proofs that a Committed Number Lies in an Interval§1.2.3我已經引述下面爲了方便：

這個證明的主要思想與[2]中的大致相同。讓$ t $，$ l $和$ s $爲三個安全參數。該協議（由Chan，Frankel和Tsiounis [7]提供，並在[8]中進行了更正，還有另一種形式的由於[14]）證明了I $中承諾的$ x \中的數字屬於$ J $ ，其中擴張率$ \＃J/\＃I $等於$ 2^{t + l + 1} $。假設$ n $是一個大的複合數，其分解因子是Alice和Bob未知的，$ g $是$ \ mathbb {Z}^{*} _ {n} $中的大單元的元素，$ h $是一個元素由$ g $生成的組中的$ g $ in b $ h $的離散對數和基$ g $的$ h $的離散對數都是Alice未知的。假設$ H $是一個輸出$ 2t $位字符串的散列函數。我們用$ E = E（x，r）= g^{x} h^{r} \ mod n $表示對$ x \ in [0，b] $的承諾，其中$ r $是隨機選擇的$ [-2^{S}的n + 1,2^{S} N-1] $。從[13]中得出的這一承諾在統計數據中沒有顯示有關$ x $到Bob的信息。方案：

方案： $（PK，{CFT}}（x，r：E = E（x，r）\ wedge x'in [-2^{t + 1} b，2^{t + l } b]）$。

1. Alice在{R} [0,2^{t + 1} b-1] $和$ \ eta \ in {{R} [ - 2^{t + l + s} n + 1,2^{t + l + s} n-1] $，然後計算出$ W = g^{\ omega} h^{eta} \ mod n $。然後，她計算$ C = H（W）$和$ c = C \ mod 2^{t} $。最後，她計算了$ D_ {1} = \ omega + xc $和$ D_ {2} = \ eta + rc $（在$ \ mathbb {Z} $中）。如果在[cb，2^{t + l} b-1] $中$ D_ {1} \，她向Bob發送$（C，D + {1}，D_ {2}）$，否則她再次啓動協議。
2. Bob在[cb，2^{t + l} b-1] $和$ C = H（g^{D_ {1}} h^{D_ {2}}中檢查$ D_ {1} } E 1 { - C ^}）$。這證明Bob在[-2^{t + 1} b，2^{t + l} b] $中有$ x \。

我在本文中實現的其他協議的成功，但是在這種情況下，我還沒有得到任何的成功，特別是因爲$ D_ {1} \在[CB，2^{T + Alice的檢查無論重試次數多少，l} b-1] $都會失敗。我很好奇編寫的協議中的邏輯是否無效，或者是否在我的代碼中。我已經查看了幾天的代碼，並且有幾個同行對它進行了審查，但都沒有發現任何可能導致此問題的原因。我引用了下面的代碼。

/** 
* Produces a CFT proof as defined in Boudot paper. 
* @param x The original message committed to in e. 
* @param r The random value in the commitment e of x. 
* @param e The value of the commitment. 
* @param b The bounding value such that x is in [0, b] 
* @param commit Object containing all the FO commitment parameters (e.g. g, h, n) and access to commit() 
* @return An array {C, D1, D2} that satisfies the CFT range-bounded commitment proof. 
*/ 
public static BigInteger[] proofCFT(BigInteger x, BigInteger r, BigInteger e, BigInteger b, FujisakiOkamotoCommitment commit) 
{ 
    SecureRandom rand = new SecureRandom(); 

    // Security parameters 
    int t = 128; // Because SHA-256 is 256-bit 
    int l = rand.nextInt(100); 
    int s = rand.nextInt(100); 

    // 2^(t+l+s) 
    BigInteger tls2 = BigInteger.valueOf(2L).pow(t+l+s); 

    // 2^(t+l)*b-1 
    BigInteger b2tl_minus1 = BigInteger.valueOf(2L).pow(t+l).multiply(b).subtract(BigInteger.ONE); 

    while(true) 
    { 
     BigInteger omega = getRandomInRange(BigInteger.ZERO, b2tl_minus1); // omega in [0, 2^(t+l)*b-1] 
     BigInteger eta = getRandomInRange(// eta in [-2^(t+l+s)*n+1, 2^(t+l+s)*n-1] 
       commit.n().multiply(tls2).negate().add(BigInteger.ONE), 
       commit.n().multiply(tls2).subtract(BigInteger.ONE)); 

     BigInteger w = commit.commit(omega, eta); // g^(omega)*h^(eta) mod n 

     byte[] hash = new byte[0]; 
     try 
     { 
      hash = MessageDigest.getInstance("SHA-256").digest(w.toByteArray()); 
     } 
     catch(NoSuchAlgorithmException nsae){} // Never occurs 

     BigInteger bigC = new BigInteger(1, hash); 
     BigInteger littleC = bigC.mod(BigInteger.valueOf(2L).pow(t)); // bigC mod 2^t 

     BigInteger d1 = x.multiply(littleC).add(omega); // d1 = omega + xc 
     BigInteger d2 = r.multiply(littleC).add(eta); // d2 = eta + rc 

     // Keep going until D1 in [c*b, b*2^(t+l)-1] 
     BigInteger lowerBound = b.multiply(littleC); 
     if(d1.compareTo(lowerBound) >= 0 && d1.compareTo(b2tl_minus1) <= 0) // Never succeeds?? 
      return new BigInteger[]{bigC, d1, d2}; 
    } 
} 

注意getRandomInRange(BigInteger max, BigInteger min)已徹底地測試和總是均勻地在該範圍內（含）返回一個值。

此外，FujisakiOkamotoCommitment始終會生成$ n $，因此其大質數因子$ p $和$ q $是安全素數。

Answer 1

經過進一步測試和研究這是從哪裏來的，我已經確定它確實是寫的算法不正確。也就是說，原始協議計算$ \ omega = _ {R} [0,2^{b（t + 1）} - 1] $，因此在[cb，2^{b （t + 1）} - 1] $和而不是 $ 2^{t + 1} b-1 $，如鏈接紙指定。我們也可以在步驟4中得到這樣的結論：$ H（g^{D_ {1}} h^{D_ {2}} E^{ - c}）$，這應該是$ H（g^{ D_ {1}} h^{D_ {2}} E^{ - c} \ mod n）$，這可能是作者本意暗示的，但是（在我看來）應該可能已經說明了。

考慮到這些錯誤以及代碼的相應調整，協議現在始終如一地通過。我有信心將此視爲Boudot論文中的錯誤印記。