Is there a standard format for compact 56-bit DES keys?

Question

DES keys are traditionally stored as 8-byte blobs, with only the high 7 bits of each byte being meaningful to the algorithm; the low bit of each byte is set so that the population count of the byte is odd. This makes DES have a key size of 56 bits, rather than 64 bits.

Is there a standard format for storing a 56-bit representation of a DES key? I was going to store them that way because it means random keys have all their bits used.

For now, I'm just concatenating the 7 bit chunks together, left to right (big-endian sense).

This is for interfacing with a legacy system that uses 3DES; thus, the parity-less format would have 168 bits = 21 bytes.

Answer 1

The one time I've seen a system compress a DES key into 7 bytes, it did it by logically placing the 8 bytes of the standard DES key into an 8x8 table, and then flipping the table along the diagonal axis, so that bit x of byte y of the standard DES key was mapped to bit 7-y of byte 7-x of the compressed key. For example, the first byte of the compressed key consisted of the msbits of all 8 bytes, and the second byte of the compressed key consisted of bit 6 of all 8 bytes, etc. This moved all the lsbits of each byte into the last byte, which was discarded.

However, I don't believe this was, in any way, standard; it just happened to be what the system I saw did. This particular transform does have the advantage that the same routine can convert both directions between the standard DES format and the compressed format (that has all the ignored bits in the last byte).

Answer 2

Microsoft Security Account Manager (SAM) Remote Protocol has a way to map 7 bytes to a DES key, similar (possibly identical) to the question's "concatenating the 7 bit chunks together, left to right (big-endian sense)".

One way to see it is that the key bits are laid out on a line, by increasing indexes of bytes and within that in big-endian order (that is, key bits are laid out by increasing bit number per DES specification, since that numbers high-order bits with the lowest number), with the low-order bits in the $8$-byte form (that is, bit number multiple of 8 per DES specification) discarded in the $7$-byte form, and regenerated when going from $7$ to $8$ bytes (as a zero bit, or perhaps using odd parity).

Otherwise said, with $1\le j\le7$, the $j$^th byte in the $7$-byte form has its $(8-j)$ high-order-bit(s) mapped to the $(8-j)$ low-except-lowest-order bit(s) of the $j$^th byte in the $8$-byte form, and its low-order $j$ bit(s) mapped to the $j$ high bit(s) of the $(j+1)$^th byte in the $8$-byte form, with no reordering of bits within each of these two segments.

As far as I know, this is not standard in any other way than having been used by some widely deployed operating systems. Also: using this convention makes it rather messy to implement the first key transformation in DES, named PC-1, starting directly from the $7$-byte form of the key; when the different convention described in poncho's answer can be viewed as being PC-1, easing a software DES implementation.