cryptography - Does DESKey preserve invalid parity bits? -

according des specification, last bit of each byte of secret key used error detection (each byte should have odd parity). hence effective key length 56 bits, not 64 bits.

however, in many use cases these parity bits not checked. used different purpose: mifare desfire cards store key version in bits, example, though original error correction purpose gets lost.

how java card implementations handle these bits? let have @ code:

deskey deskey = ... //a single des key instance byte[] inputkey = new byte[8]; inputkey[7] = (byte) 0x03; //explicitly invalid parity bit in last byte deskey.setkey(inputkey, (short) 0); byte[] outputkey = new byte[8]; deskey.getkey(outputkey, (short) 0); 

is guaranteed inputkey , outputkey arrays contain same data in end, invalid parity bits in inputkey? performed several experiments few card types , preserve data put in parity bits, didn't find mention in java card specification behaviour guaranteed.

this piece of information important me; otherwise have store "invalid parity bits" separated key instance.

if not in specifications not guaranteed. it's simple; there isn't separate specification card implementers says otherwise (and if there was, might change without touching original definition).

operations on keys can tricky regard attacks. there lot said keeping key data intact , not iterate on key bits using generic cpu. also, might tricky when other operations performed on key data such calculating key check value using hash function or using same key input mac (symmetric signature).

it's of course possible perform parity operation on key bits using own code. can compare result test vectors or keys generated using java secretkeyfactory. however, since parity bits don't used in key calculations, needed if want export key out of device. again, note performing additional operations on key data dangerous , may break kinds of security tests/proofs/certifications.

note java card implementations (or rather, hardware of underlying chip) perform checksums on persistent (eeprom/flash) memory anyway. it's keys protected java card implementation (or 1 of underlying layers). regards protection against unforeseen alterations of data: wouldn't worry overly much. don't need des parity bits that.

---

ok, felt doing bit fiddling, here's java card code set parity (i'll let loop , inlining , stuff, if don't mind). these calculations should (near) constant time.

/**  * method takes byte value <code>b</code> , sets or unsets least significant bit  * of value in such way parity of <code>b</code> odd.  * method returns either <code>b</code> or <code>b ^ 1</code>.  *   * @param b byte value  * @return <code>b</code> des parity  */ public static byte makedesparity(final byte b) {     byte x = b;     // trick calculate odd parity in lsb of x     x ^= x >>> 4;     x ^= x >>> 2;     x ^= x >>> 1;     // want parity in lsb: ~x     // least significant bit: ~x & 1     // xor b: ~x & 1 ^ b     return (byte) (~x & 1 ^ b); }  /**  * method takes byte value <code>b</code> , returns true if , if  * byte has odd parity.  *   * @param b byte value  * @return true if <code>b</code> has des parity  */ public static boolean hasdesparity(byte b) {     // trick calculate odd parity in lsb of b     b ^= b >>> 4;     b ^= b >>> 2;     b ^= b >>> 1;     // check if last bit has indeed been set     return (b & 1) != 0; }