Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Main cipher objective : Generate a keyed CSPRN stream, that does not expose useful information about the state of the CSPRNG, and xor this with the plaintext. To prevent an attacked who could somehow recover state or key information from one ciphertext from using this on other ciphertexts, a "random section", here called an IV, is appended to the original key, before it is scheduled (hashed into the state of the CSPRNG).

The question concerns one final part of the algorithm not mentioned above : to transmit this "once generated" IV, it is encrypted with the original key (after scheduling the original key into the state of the CSPRNG), and appended to the output. How secure is this formulation ? Where original key is used 1 time to encrypt the random IV, and a novel key formed from original key + unencrypted IV is used 1 time to encrypt plaintext ?

As a list of instructions, the use of the IV proceeds like this :

  1. Generate 37 random 32 bit integers
  2. Pack these into bytes
  3. Using the user key (which has been scheduled), encrypt these bytes, so the IV can be saved to file
  4. Concatenate the original (unscheduled) user key with the unencrypted IV bytes
  5. Reschedule this key, to give the final state of the stream generator before encryption

The encryption combination function is symmetric, just xor.

share|improve this question
    
An IV is used to ensure that a cipher produces different output for each encryption, even when using the same key. For block ciphers it should be the same size as the block, for stream ciphers it varies. Provided that it's generated with a CSPRNG, and is unique for each encryption, I don't think the 'usage' can be 'stronger'. What exactly are you trying to achieve with the above code? Are there any particular concerns you're trying to mitigate? –  hunter Jan 30 '13 at 16:17
    
Okay concerns : 1) It's not CSPRING, I generate two 1184 bit random numbers via python's random.randint() (37*32 bit words packed), then take the middle 1184 bits of the product. I think it's good, but not great. 2) Even though the key is scheduled I am concerned that a) the scheduled key_a is used to encrypt the IV, b) the (unscheduled) key_a is combined with the (unencrypted) IV and rescheduled, then the (encrypted) IV is prepended to the ciphertext. It just seems that could not someone get some correlation from that prepended encrypted IV? Even though all stream outputs are incompressible. –  Cris Stringfellow Jan 30 '13 at 16:42
    
It's difficult to understand what you're even trying to accomplish. You're doing a lot of extremely complex things and I'm not sure there's necessarily a reason. Can you edit your post to include what it is exactly you're trying to do? –  Stephen Touset Jan 30 '13 at 18:39
    
@StephenTouset Yes, I will. Thanks. –  Cris Stringfellow Jan 31 '13 at 2:24
add comment

1 Answer 1

up vote 3 down vote accepted

Different modes of operation have different requirements. For example, the IV for CBC mode should be generated with a CSPRNG, where as the IV for CTR mode just needs to be unique for each encryption. In terms of cryptography, the 'random' functions found in many languages are more predictable than you might imagine.

That being said, there's absolutely no need to encrypt your IV. It doesn't need to be secret, and can be transmitted/stored as clear text.

Encrypting the IV might add some level of security, but if you plan to do that then you should use a key which is independent of the key used for the initial encryption. Independent not only means unique, it also means that it's derived from a different source (which can make things unnecessarily complicated).

share|improve this answer
    
By the initial encryption do you mean where the IV is encrypted? Or when the plaintext is? –  Cris Stringfellow Jan 30 '13 at 17:42
    
The plaintext one. –  hunter Jan 30 '13 at 17:52
    
Why should it be so independent? –  Cris Stringfellow Jan 30 '13 at 17:56
1  
There's quite a lot of discussion regarding this topic here –  hunter Jan 30 '13 at 18:03
    
Thanks I'll check that. –  Cris Stringfellow Jan 30 '13 at 18:09
show 3 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.