Java BigInteger bitLength（）方法忽略前導0位

Question

Java：jre1.8.0_45

我完成了橢圓曲線類的調試，並記錄了鍵的所有特征，我還記錄了鍵的BIT長度（橢圓曲線並不總是偶數位）。

我通過BigInteger顯示Keys的位長度：

ECPrivateKey oPK=generate the key ...
BigInteger oBI=oPK.getS(); 
MetaLogBook.debug("Key Size in Bits :"+oBI.bitLength()+
                "\nRaw Key Hex      : 0x"+oBI.toString(16)).toUpperCase()+"\n"+);

雖然密鑰總是正確表示並且加密工作正常，但是比特大小會波動。 很多時候它是正確的（571），但有時它是幾個位。

所以我開始生成AES-256密鑰，我注意到它們通常是256位，但也不時有幾位關閉。 所以它與Elliptic Curve中的奇數位無關。

經過長時間的搜索，我認為我找到了一個解釋，或者至少是一個解釋的開頭，但我不知道這是預期還是Java Bug。

當我看到這個64字節十六進制（32字節AES 256位密鑰）的位長度為254而不是256時，我可以得出結論。

0x27006F59EA138FE01FBE1F554253DBDD84D73719E77088907357C6FA6B60F170

最后一個半字節是0，所以如果不計算尾隨0位，那么我在bitLength（）中至少有4位短，而我只有2位短。

然后我發現我的密鑰的第一個半字節以2或二進制0010開始。所以我認為BigInteger.bitLength（）沒有計算LEADING零BITS。 我重復了很多次，行為似乎是一致的（通常我認為每個人都可以重現這一點）。

我想知道這是否是BigInteger.bitLength（）的WANTED行為，或者這可能是一個錯誤。 我不會問這個問題是不是我認為Java中的許多加密代碼可能依賴於BigInteger（包括提供者）而我無法想象他們不會遇到這個問題。

TIA

Answer 1

它按預期和記錄的方式工作。

從文檔 ：

返回此BigInteger的最小二進制補碼表示中的位數，不包括符號位。 對於正BigIntegers，這相當於普通二進制表示中的位數。

注意這里的“最小”部分 - 例如，十進制值5可以表示為00000000000000000000000000101或101 ...但101是最小表示，因此位長度為3。