- html - 出于某种原因,IE8 对我的 Sass 文件中继承的 html5 CSS 不友好?
- JMeter 在响应断言中使用 span 标签的问题
- html - 在 :hover and :active? 上具有不同效果的 CSS 动画
- html - 相对于居中的 html 内容固定的 CSS 重复背景?
根据 DES 规范, key 的每个字节的最后一位用于错误检测(每个字节应具有奇校验)。因此有效 key 长度是 56 位,而不是 64 位。
但是,在许多用例中,不会检查这些奇偶校验位。有时它们甚至用于完全不同的目的:例如,Mifare DESFire 卡将 key 版本存储在这些位中,即使最初的纠错目的丢失了。
Java Card 实现如何处理这些位?让我们看看这段代码:
DESKey desKey = ... //a single DES key instance
byte[] inputKey = new byte[8];
inputKey[7] = (byte) 0x03; //explicitly invalid parity bit in the last byte
desKey.setKey(inputKey, (short) 0);
byte[] outputKey = new byte[8];
desKey.getKey(outputKey, (short) 0);
inputKey
和
outputKey
数组最终将包含相同的数据,即使
inputKey
中的奇偶校验位无效?我对几种卡类型进行了几次实验,它们都保留了我放在这些奇偶校验位中的任何数据,但是我在 Java Card 规范中没有发现任何提到这种行为是有保证的。
最佳答案
如果它不在规范中,则无法保证。真的就是这么简单;没有针对卡实现者的单独规范另有说明(如果有,那可能会在不触及原始定义的情况下发生变化)。
在攻击方面,对 key 的操作可能很棘手。因此,关于保持关键数据完好无损,而不是使用通用 CPU 迭代关键位,有很多话要说。此外,当对 key 数据执行其他操作时可能会很棘手,例如使用哈希函数计算 key 检查值或使用相同的 key 作为 MAC(对称签名)的输入。
当然,完全可以使用您自己的代码对关键位执行奇偶校验操作。您可以将结果与测试向量或使用 Java 生成的 key 进行比较 SecretKeyFactory
.但是,由于在 key 计算中不使用奇偶校验位,因此仅当您想将 key 导出到设备外时才需要这样做。但再次请注意,对关键数据执行额外操作是危险的,可能会破坏各种安全测试/证明/认证。
请注意,大多数 Java Card 实现(或者更确切地说,底层芯片的硬件)很可能会在所有持久(EEPROM/闪存)内存上执行校验和。 key 也很可能受到 Java Card 实现(或底层之一)的保护。因此,关于防止数据意外更改的保护:我不会过分担心。您不需要 DES 奇偶校验位。
好的,我想稍微摆弄一下,所以这里是自己设置奇偶校验的 Java Card 代码(如果您不介意,我会让您执行 for 循环和内联等操作)。这些计算应该是(接近)恒定时间。
/**
* This method takes byte value <code>b</code> and then sets or unsets the least significant bit
* of that value in such a way that the parity of <code>b</code> is odd.
* So this method returns either <code>b</code> or <code>b ^ 1</code>.
*
* @param b the byte value
* @return <code>b</code> with DES parity
*/
public static byte makeDESParity(final byte b) {
byte x = b;
// trick to calculate odd parity in the lsb of x
x ^= x >>> 4;
x ^= x >>> 2;
x ^= x >>> 1;
// but we want even parity in the lsb: ~x
// get the least significant bit: ~x & 1
// xor that with b: ~x & 1 ^ b
return (byte) (~x & 1 ^ b);
}
/**
* This method takes byte value <code>b</code> and returns true if and only if
* the byte has odd parity.
*
* @param b the byte value
* @return true if <code>b</code> has DES parity
*/
public static boolean hasDESParity(byte b) {
// trick to calculate odd parity in the lsb of b
b ^= b >>> 4;
b ^= b >>> 2;
b ^= b >>> 1;
// check if last bit has indeed been set
return (b & 1) != 0;
}
关于cryptography - DESKey 是否保留无效的奇偶校验位?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45687445/
根据 DES 规范, key 的每个字节的最后一位用于错误检测(每个字节应具有奇校验)。因此有效 key 长度是 56 位,而不是 64 位。 但是,在许多用例中,不会检查这些奇偶校验位。有时它们甚至
我正在 Node.js 中实现一个协议(protocol)。这个协议(protocol)使用CBC模式的3DES加密,好吧。 但是为了加密/解密,我需要将 14 字节 DES key 扩展/扩展为 1
我是一名优秀的程序员,十分优秀!