Java BigInteger bitLength()方法将忽略前导0位 [英] Java BigInteger bitLength() method ignores leading 0-bits

问题描述

Java:jre1.8.0_45

Java : jre1.8.0_45

我完成了对椭圆曲线类的调试，并记录了按键的所有特征，同时还记录了按键的BIT长度(使用椭圆曲线时，位长并不总是偶数).

I finished debugging my Elliptic Curve class and in logging all characteristics of the keys I also log the BIT length of the keys (which with Elliptic Curve is not always an even number of bits).

我通过BigInteger显示密钥的位长:

I display the bit length of the Keys via a BigInteger:

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)，但有时会有些偏离.

While the key is always correctly represented and ciphering works fine, the bit size however fluctuates. Many times it is correct (571) but from time to time it is a few bits off.

因此，我开始生成AES-256密钥，我注意到它们通常是256位，但有时会掉一些位.因此，它与椭圆曲线中的奇数位数无关.

So I started to generate AES-256 keys and I noticed that they are often 256 bits but also from time to time a few bits off. So it had nothing to do with the odd number of bits in Elliptic Curve.

经过长时间的搜索，我认为我找到了一个解释，或者至少是一个解释的开始，但是我不知道这是意图还是Java错误.

After a long search I THINK I found an explanation, or at least a beginning of an explanation, but I don't know if this is INTENDED or a Java Bug.

当我看到这个64字节的十六进制(32字节AES 256位密钥)的显示位长为254而不是256时，我可以得出一个结论.

When I saw that this 64 bytes hex (32 byte AES 256 bit key) had a bit length of 254 displayed in stead of 256 I could draw a conclusion.

0x27006F59EA138FE01FBE1F554253DBDD84D73719E77088907357C6FA6B60F170

0x27006F59EA138FE01FBE1F554253DBDD84D73719E77088907357C6FA6B60F170

最后一个半字节为0，因此，如果不计算尾随的0位，则bitLength()中我至少要短4位，而我只有2位短.

The last nibble is 0, so if trailing 0-bits would not be counted then I would have been at least 4 bits short in the bitLength() and I was only 2 bits short.

然后我想到我的钥匙的第一个半字节以2或二进制0010开头.因此我发现BigInteger.bitLength()不算出LEADING零位.我重复了几次，这种行为似乎是一致的(通常我认为每个人都可以重现).

Then it occurred to me that the first nibble of my key started with a 2 or binary 0010. So I figured that the BigInteger.bitLength() didn't count the LEADING zero BITS. I repeated this a number of times and the behaviour seems consistent (normally I think everyone can reproduce this).

我想知道这是否是BigInteger.bitLength()的通缉行为，或者这是否可能是错误.我不会问这个问题，是否不是我假设Java中的许多加密代码都可能依赖BigInteger(包括提供程序)，而且我无法想象他们不会遇到这个问题.

I would like to know if this is the WANTED behaviour of BigInteger.bitLength() or if this could possibly be a bug. I wouldn't have asked the question if it weren't that I assume that many crypto code in Java may rely on BigInteger (including providers) and I cannot imagine they wouldn't have ran into this problem.

TIA

推荐答案

它正在按预期方式工作并已记录在案.

It's working as intended and as documented.

从文档:

返回此BigInteger的最小2补码表示形式中的位数，不包括符号位.对于正数BigInteger，这等于普通二进制表示形式的位数.

Returns the number of bits in the minimal two's-complement representation of this BigInteger, excluding a sign bit. For positive BigIntegers, this is equivalent to the number of bits in the ordinary binary representation.

请注意此处的最小"部分-例如，十进制值5可以表示为00000000000000000000000000101或101 ...，但是101是最小表示，因此位长为3.

Note the "minimal" part here - for example the decimal value 5 can be represented as 00000000000000000000000000101 or 101... but 101 is the minimal representation, so the bit length is 3.

这篇关于Java BigInteger bitLength()方法将忽略前导0位的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！