为什么要在散列之前删除 java 字节数组中的前导所有零字节

Question

这个问题是关于在java中对字节数组进行哈希处理之前对字节数组执行的操作。

我试图理解为什么在多个 srp 加密库中，前导零字节（如果有的话）在散列之前被删除。

例如：这是来自充气城堡

/**
 * Return the passed in value as an unsigned byte array.
 *
 * @param value value to be converted.
 * @return a byte array without a leading zero byte if present in the signed encoding.
 */
public static byte[] asUnsignedByteArray(int length, BigInteger value)
{
    byte[] bytes = value.toByteArray();
    if (bytes.length == length)
    {
        return bytes;
    }
    int start = bytes[0] == 0 ? 1 : 0;
    int count = bytes.length - start;
    if (count > length)
    {
        throw new IllegalArgumentException("standard length exceeded for value");
    }
    byte[] tmp = new byte[length];
    System.arraycopy(bytes, start, tmp, tmp.length - count, count);
    return tmp;
}

或者这是来自 nimbus SRP：

public static byte[] toUnsignedByteArray(final BigInteger bigInteger) {
    byte[] bytes = bigInteger.toByteArray();
    byte[] result = toUnsignedByteArray(bytes);
    // remove leading zero if any
    if (bytes[0] == 0) {
        byte[] tmp = new byte[bytes.length - 1];
        System.arraycopy(bytes, 1, tmp, 0, tmp.length);
        return tmp;
    }
    return bytes;
}

购买的例子基本上会掉掉那个前导零。这些库中的方法被称为"toUnsignedByteArray"，尽管我不明白为什么删除前导零会使字节数组无符号。即它只删除零字节，然后下一个字节可能是负数，即下一个字节成为最左边的字节（在大印度），字节中最左边的位是符号位，可以根据字节设置或取消设置，所以如果我正确理解字节数组的结构，这些方法不应该首先调用"toUnsignedByteArray"。然而，最重要的问题是为什么我们需要删除那个零字节，以防它全是零

以下是来自 srp rfc 5054 附录 A 的测试向量示例。我们从 A 和 B 计算 U。其中 B 的零字节恰好是二进制中的所有零，即如果我们将 B 打印为字节数组，我们将得到以下值

public static final B = new BigInteger("BD0C61512C692C0CB6D041FA01BB152D4916A1E77AF46AE105393011BAF38964DC46A0670DD125B95A981652236F99D9B681CBF87837EC996C6DA04453728610D0C6DDB58B318885D7D82C7F8DEB75CE7BD4FBAA37089E6F9C6059F388838E7A00030B331EB76840910440B1B27AAEAEEB4012B7D7665238A8E3FB004B117B58", 16);

[0， -67， 12， 97， 81， 44， 105， 44，

12， -74， -48， 65， -6， 1， -69， 21， 45, 73, 22, -95, -25, 122, -12, 106, -31, 5, 57, 48, 17, -70, -13, -119, 100, -36, 70, -96, 103, 13, -47, 37, -71, 90, -104, 22, 82, 35, 111, -103, -39, -74, -127, -53, -8, 120, 55, -20, -103, 108, 109, -96, 68, 83, 114, -122, 16, -48, -58, -35, -75, -117, 49, -120, -123, -41, -40, 44, 127, -115, -21, 117, -50, 123, -44, -5, -86, 55, 8, -98, 111, -100, 96, 89, -13, -120, -125, -114, 122, 0, 3, 11, 51, 30, -73, 104, 64, -111, 4, 64, -79, -78, 122, -82, -82, -21, 64, 18, -73, -41, 102, 82， 56， -88， -29， -5， 0， 75， 17， 123， 88]

二进制

打印的字节零：00000000

现在我明白了，出于某种原因，删除该字节很重要（尽管我不确定）我的意思是，既然这些测试向量使用这两个库正确计算，它应该正确编程，对吗？但是我不明白为什么我们需要删除前导零字节。它有什么问题。如果我放弃该前导 zeor 字节并尝试从没有前导零字节的字节数组中创建另一个 BigInteger，那么在这种情况下我会得到一个完全不同的数字，甚至是负数。所以删除那个零字节对我来说没有任何场景。欢迎任何解释。

Answer 1

名称

中的"无符号"可能有点误导; 不是删除 0 字节使其无符号，只是假设BigInteger包含无符号数字。

在这些情况下删除的 0 字节不会更改值，就像 01 或 001 的值与 1 相同一样。

出于各种原因，删除零很重要：

1. 不会因不必要的 0 字节而浪费空间。
2. 在比较字节数组时使表示一致。
3. （与您所指的上下文最相关）前面带有额外 0 的字节数组的哈希与没有额外 0 的字节数组的哈希不同。哈希函数毕竟不知道这是一个数字，在这种情况下 0 毫无意义。想象一下，如果这是一个文件，字节0:1:2:3，而不是一个字节1:2:3的文件。您不会期望具有不同长度的文件的哈希值相同。

另请注意，是从开头还是结尾删除 0 字节取决于整数表示的字节序。

更新：澄清删除 0 字节：

虽然从任何旧字节数组的开头或结尾删除 0 字节会更改值，但在您引用的情况下，我们谈论的是整数的表示形式。如果 0 字节具有重要性，例如，您要往返一些二进制数据，则不适合将该二进制数据加载到 BigInteger 类中。我指的是我原来的例子，你不会认为1和01是不同的数字吧（尽管你会认为它们是不同的字符串）？

更新：关于字节序的说明：

整数可以在内存中以不同的方式表示。如果你看到数字20（普通十进制），你知道2指的是十个数字，但这只是一个约定。我们可以将二十个倒写为02，并将最大的单位放在数字的末尾。同样，在计算机中，数字的顺序可以是我们通常熟悉的方式，也可以是"倒退"的。鉴于此，不影响数字值的 0 可能位于字节数组的开头或结尾，我们必须知道在处理字节数组时应该"读取"字节