Is there any library or code for DES which take 7 byte key? [closed]

Question

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.

Closed 9 years ago.

Improve this question

Do we have any library or any mechanism where we can use true 7 byte key for DES instead of 8 byte key. I need it for keys analysis in DES and 8 byte key requirement for associated library is creating problem in getting actual keys analysis.

Answer 1

As explained in http://en.wikipedia.org/wiki/Data_Encryption_Standard, the 8-byte key for DES is just a 56-bit key in 8 bytes with odd parity check added:

The key is nominally stored or transmitted as 8 bytes, each with odd parity. According to ANSI X3.92-1981, section 3.5:

One bit in each 8-bit byte of the KEY may be utilized for error detection in key generation, distribution, and storage. Bits 8, 16,..., 64 are for use in ensuring that each byte is of odd parity.

(end quote)

So given an 8-byte key I can generate a 7-byte key by dropping the parity check bits and reformatting, and given a 7-byte key I can generate an 8-byte key by reformatting and adding parity check bits. It should therefore be easy to produce wrappers to make a library for one key format look like a library for another - or are you having some other problem I haven't noticed?

Answer 2

In DES a key is comprised of 8 bytes with the LSB a parity bit, a nice and regular structure. There's an implication there for the relationship between input bytes and Permuted Choice 1, which loads the two 28 bit C and D Registers.

In parlance of the NBS standard a Permuted Choice is a selection permutation not using all the values of a greater whole.

Historically any DES implementation that used 7 bytes wasn't compatible where there are several FIPS/Nist pubs specifying key/ciphertext/plaintext triplets.

If you have a need for a 56 bit number representing a key there's an implication you're using or storing them in a tabular fashion. Otherwise you could simply guarantee the parity bit is either correct or say '0'. 'Packed' keys are only of interest for saving storage space.

All that said and done if you need a 56 bit number representing a key you could represent 8 bytes of key in a 64 bit value and after identifying the parity bit locations with respect to endian-ness, shift the 64 bit array value obliterating the parity bits one at a time in 8 operations on a 64 bit machine, leaving 56 'effective' key bits.

On a 32 bit or smaller machine you'd also have to track byte position to keep track of bit shift offsets and would have to deal with bits moving between bytes to pack bits into 7 bytes.

For a 32 bit machine you could pack two 32 bit values into 28 bits in opposite directions then merge the proper 4 bits of the second one into the first followed by shifting the second value down 8 bits.

For a big-endian bit in byte numbering system 1 to 8 with bit 8 the LSB (from the standard) Bits 1-4 go to the C register, with only four bit 4 values from 8 successive bytes of an input key (described as an input array of bits). The D block shares bit 4 and uses bits 5-7 to derived 28 bits:

The bigger issue here may be the ability to communicate any interesting finding in terms of keys useful to those dealing with an 8 byte key representation. It may be handy to have an inverse function available as well.

There's also a relationship between round keys and the C and D concatenated block, shown in Carl Meyers and Stephen Metyas book "Cryptography, A New Dimension in Computer Security', subtitled 'A Guide for the Design and Implementation of Secure Systems', Wiley Interscience, 1982, ISBN-0-471- 04892-5.

I recreated the table using a derivative of the original BSD libcrypt source. The significance of this is that C and D bits don't mix in the two 24 bit values derived from Permuted Choice 2 (which is visible in selected key (KS) in round 16 of the table).

  Bit  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24  
KS  
   1  15 18 12 25  2  6  4  1 16  7 22 11 24 20 13  5 27  9 17  8 28 21 14  3  
   2  16 19 13 26  3  7  5  2 17  8 23 12 25 21 14  6 28 10 18  9  1 22 15  4  
   3  18 21 15 28  5  9  7  4 19 10 25 14 27 23 16  8  2 12 20 11  3 24 17  6  
   4  20 23 17  2  7 11  9  6 21 12 27 16  1 25 18 10  4 14 22 13  5 26 19  8  
   5  22 25 19  4  9 13 11  8 23 14  1 18  3 27 20 12  6 16 24 15  7 28 21 10  
   6  24 27 21  6 11 15 13 10 25 16  3 20  5  1 22 14  8 18 26 17  9  2 23 12  
   7  26  1 23  8 13 17 15 12 27 18  5 22  7  3 24 16 10 20 28 19 11  4 25 14  
   8  28  3 25 10 15 19 17 14  1 20  7 24  9  5 26 18 12 22  2 21 13  6 27 16  
   9   1  4 26 11 16 20 18 15  2 21  8 25 10  6 27 19 13 23  3 22 14  7 28 17  
  10   3  6 28 13 18 22 20 17  4 23 10 27 12  8  1 21 15 25  5 24 16  9  2 19  
  11   5  8  2 15 20 24 22 19  6 25 12  1 14 10  3 23 17 27  7 26 18 11  4 21  
  12   7 10  4 17 22 26 24 21  8 27 14  3 16 12  5 25 19  1  9 28 20 13  6 23  
  13   9 12  6 19 24 28 26 23 10  1 16  5 18 14  7 27 21  3 11  2 22 15  8 25  
  14  11 14  8 21 26  2 28 25 12  3 18  7 20 16  9  1 23  5 13  4 24 17 10 27  
  15  13 16 10 23 28  4  2 27 14  5 20  9 22 18 11  3 25  7 15  6 26 19 12  1  
  16  14 17 11 24  1  5  3 28 15  6 21 10 23 19 12  4 26  8 16  7 27 20 13  2  

  Bit 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48  
KS  
   1  42 53 32 38 48 56 31 41 52 46 34 49 45 50 40 29 35 54 47 43 51 37 30 33  
   2  43 54 33 39 49 29 32 42 53 47 35 50 46 51 41 30 36 55 48 44 52 38 31 34  
   3  45 56 35 41 51 31 34 44 55 49 37 52 48 53 43 32 38 29 50 46 54 40 33 36  
   4  47 30 37 43 53 33 36 46 29 51 39 54 50 55 45 34 40 31 52 48 56 42 35 38  
   5  49 32 39 45 55 35 38 48 31 53 41 56 52 29 47 36 42 33 54 50 30 44 37 40  
   6  51 34 41 47 29 37 40 50 33 55 43 30 54 31 49 38 44 35 56 52 32 46 39 42  
   7  53 36 43 49 31 39 42 52 35 29 45 32 56 33 51 40 46 37 30 54 34 48 41 44  
   8  55 38 45 51 33 41 44 54 37 31 47 34 30 35 53 42 48 39 32 56 36 50 43 46  
   9  56 39 46 52 34 42 45 55 38 32 48 35 31 36 54 43 49 40 33 29 37 51 44 47  
  10  30 41 48 54 36 44 47 29 40 34 50 37 33 38 56 45 51 42 35 31 39 53 46 49  
  11  32 43 50 56 38 46 49 31 42 36 52 39 35 40 30 47 53 44 37 33 41 55 48 51  
  12  34 45 52 30 40 48 51 33 44 38 54 41 37 42 32 49 55 46 39 35 43 29 50 53  
  13  36 47 54 32 42 50 53 35 46 40 56 43 39 44 34 51 29 48 41 37 45 31 52 55  
  14  38 49 56 34 44 52 55 37 48 42 30 45 41 46 36 53 31 50 43 39 47 33 54 29  
  15  40 51 30 36 46 54 29 39 50 44 32 47 43 48 38 55 33 52 45 41 49 35 56 31  
  16  41 52 31 37 47 55 30 40 51 45 33 48 44 49 39 56 34 53 46 42 50 36 29 32  

This almost says your 56 bit number should be concatenated from the C and D Register values so there's a discernible relationship with round keys while allowing you to index based on C and/or D values.

Answer 3

I tried editing pyDes library code I just took 7 byte key and converted back to 64 bits by padding '0' to every multiple of 8th positions of bits. so the analysis on 7 byte-key actually required for algorithm hopefully is gained and the the parity bits are taken as 0 (that is not associated to my key now) :) . please comment if my key still is not solely for DES algorithm..