User:David MacQuigg/Sandbox/Cipher Security: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>David MacQuigg
(New page: The design of a secure cryptographic system requires attention to some basic principles. We will illustrate these principles with a simple Stream Cipher, but they are applicable to [[...)
 
imported>David MacQuigg
No edit summary
 
Line 2: Line 2:


   Plaintext                  XOR Gates                      Ciphertext
   Plaintext                  XOR Gates                      Ciphertext
   P -----> [PRE] ---> (+) ---> (+) ---> (+) ---> (+) ---------------> C
   P -----> [PRE] ---> (+) ---> ... ---> (+) ---> (+) ---------------> C
                         ^        ^        ^        ^        |Feedback
                         ^        ^        ^        ^        |Feedback
                         |        |        |        |        |
                         |        |        |        |        |
                      Gen1    Gen2    ...      GenN  <--/   Keystream
        Keystream    Gen1    Gen2    ...      GenN  <--/
                        ^        ^        ^        ^           Generator
          Generators    ^        ^        ^        ^
                         |        |        |        |
                         |        |        |        |
     Key ---> [Hash] ---> -------> -------> ------->
     Key ---> [Hash] ---> -------> -------> ------->    


1) Never start processing raw plaintext with a freshly initialized cryptosystem.  Assume the worst-case plaintext, maybe even all zeroes.  This will generate a set pattern in the ciphertext that can reveal something about the key.  A preprocessing step should as a minimum, add a block of chaff at the beginning of each message, or after every initialization of the keys.
1) Never start processing raw plaintext with a freshly initialized cryptosystem.  Assume the worst-case plaintext, maybe even all zeroes.  This will generate a set pattern in the ciphertext that can reveal something about the key.  A preprocessing step should as a minimum, add a block of chaff at the beginning of each message, or after every initialization of the keys.
Line 25: Line 25:


=== Example Design ===
=== Example Design ===
Gen1 could be a simple LFSR, and the other generators could implement messy nonlinear functions.  Even if a few of the other generators get stuck in a "short cycle", the LFSR will continue to ensure unchanging patterns and good statistics at the output.
Gen1 could be a simple LFSR, and the other generators could implement messy nonlinear functions.  Even if a few of the other generators get stuck in a "short cycle", the LFSR will continue to ensure ever changing patterns and good statistics at the output.

Latest revision as of 15:55, 18 March 2010

The design of a secure cryptographic system requires attention to some basic principles. We will illustrate these principles with a simple Stream Cipher, but they are applicable to Block Ciphers as well.

  Plaintext                   XOR Gates                      Ciphertext
  P -----> [PRE] ---> (+) ---> ... ---> (+) ---> (+) ---------------> C
                       ^        ^        ^        ^        |Feedback
                       |        |        |        |        |
        Keystream     Gen1     Gen2     ...      GenN   <--/
         Generators    ^        ^        ^        ^
                       |        |        |        |
   Key ---> [Hash] ---> -------> -------> ------->      

1) Never start processing raw plaintext with a freshly initialized cryptosystem. Assume the worst-case plaintext, maybe even all zeroes. This will generate a set pattern in the ciphertext that can reveal something about the key. A preprocessing step should as a minimum, add a block of chaff at the beginning of each message, or after every initialization of the keys.

2) Use feedback or some other scheme, which along with the chaff, will ensure that there is never any repetition of patterns at the output, even if the same message is repeated day after day.

3) Use plenty of key bits distributed to all parts of the key generator, even if (for convenience) the input key might be shorter. This, along with feedback, will ensure that if some of the key bits are revealed, others will maintain security.

4) In the keystream generator, use simple, predicable components, like an LFSR, to ensure long sequences with no repetition, and to ensure the output is indistinguishable from white noise.

5) In the keystream generator, use complex components to ensure no algebraic attack. Typically, this involves highly nonlinear operations, with many "product terms", like an S-box.

6) Combine the simple and complex components in a way that gains the benefits of all, but avoids the vulnerabilities of any one.

7) Use modular design, so that modules with radically different internals may be easily mixed, and replaced if necessary.

Example Design

Gen1 could be a simple LFSR, and the other generators could implement messy nonlinear functions. Even if a few of the other generators get stuck in a "short cycle", the LFSR will continue to ensure ever changing patterns and good statistics at the output.