DES实现中32位掩码(0xFFFFFFFFL)的作用及结果差异问题

这个问题的核心其实是Java里int类型的32位有符号限制、溢出行为，以及对无符号位操作的模拟——咱们一步步拆解，就能明白为什么掩码这么关键，以及去掉它后结果天差地别的原因：

1. 先看你给出的数值细节 #

你例子里的leftHalf=1048560，换算成二进制的话，它的最高有效位在第19位（因为2^19=524288，2^20=1048576，1048560刚好比2^20小16），也就是说这个数只占了int的低20位，高12位都是0。

2. 不带掩码的情况：notMasked = (leftHalf << 28) | rightHalf #

这里的问题出在**int类型的移位溢出**：

• leftHalf是int类型（32位有符号数），执行leftHalf <<28时，相当于把所有位向左移动28位。但leftHalf的最高位在第19位，19+28=47，已经超出了int的32位范围（0~31位），所以所有有效位都被移出了int的存储范围，结果直接变成了**0**。
• 接下来0 | rightHalf自然就等于rightHalf本身，也就是你看到的notMasked=109436546。

如果leftHalf是个负数（比如最高位为1的int），情况会更糟：直接转long时会触发符号位扩展，高32位全变成1，移位后会完全破坏原本的位结构。

3. 带掩码的情况：connectedHalves = ((leftHalf & 0xFFFFFFFFL) << 28) | (rightHalf & 0xFFFFFFFFL) #

0xFFFFFFFFL是64位long类型的“低32位全1”掩码，它的作用是把int类型转换成对应的无符号32位long值：

• 当int类型的leftHalf和0xFFFFFFFFL做与运算时，Java会先把leftHalf提升为long类型（因为操作数是long）。对于正数leftHalf来说，提升后是0x00000000000FFFF0（对应十进制1048560），与掩码运算后还是这个值；如果leftHalf是负数，掩码会把它转成无符号的32位long（比如int的-1会变成0xFFFFFFFFL）。
• 接下来对long类型执行<<28移位，就不会有溢出问题了：0x00000000000FFFF0 <<28 = 0x00000000FFFF00000000（对应十进制281469186048000）。
• 最后和处理好的rightHalf（同样通过掩码转成无符号long）做或运算，就能正确拼接出64位的完整值：281469186048000 | 109436546 = 281470791179906，也就是你看到的connectedHalves。

4. 总结：掩码的意义 #

DES算法中需要处理的是无符号的32位数据块，但Java没有原生的无符号int类型。0xFFFFFFFFL掩码的作用就是模拟无符号int的行为：

• 把int转成long后，强制高32位为0，低32位完整保留原int的所有位；
• 避免了int移位时的溢出问题，以及负数转long时的符号位扩展问题；
• 确保后续的移位、拼接等位运算完全符合DES算法对64位数据块的操作要求。

内容的提问来源于stack exchange，提问作者Michal Fiala