0
$\begingroup$

I implemented a Stream Cipher using Cryptographically Secure Random Numbers for the key values. The key stream was as long as the plaintext stream. This key data set won't be reused. Have I met all the requirements for a truly theoretically unbreakable encryption process?

I know programmers without the math or general crypto background are strongly encouraged NOT to avoid AES, Two Fish, etc. in favor of their own, amateur approaches. Yet I can't see where I've missed a requirement. I look forward to those with domain expertise to show me if I've failed to understand something here. Thank you.

Improve this question
$\endgroup$
4
  • $\begingroup$ So assuming that you used a PRNG (in contrary to a TRUE random number generator) to generate the key stream, i believe your stream cipher is at most as "secure" as the PRNG. Though the PRNG might be cryptographically secure, it is not "unbreakable" in terms that the pseudo random generated key can be recovered. $\endgroup$
    – Fleeep
    Commented Mar 8, 2016 at 6:14
  • $\begingroup$ Another issue to worry about is key management. If you have to store a key as long as the content, your scheme is by design limited to small plaintexts (you don't want to spend 4GB to store the encryption of a 2GB file). Likewise, if the key was to be transmitted, the communication overhead would be huge. Summarizing some of the comments: understand why One Time Pad is not used in practice, learn about security definitions (to know what can be expected as theoretically unbreakable) and don't try to reinvent the wheel! $\endgroup$
    – Sergio A. Figueroa
    Commented Mar 8, 2016 at 9:29
  • $\begingroup$ Fleep: Nope. I got the rnds from atmospheric noise. TRNG not PRNG. So I ask again, given a key length as long as plaintext, Cryptographically Secure Random numbers, no key reuse, how secure is my amateur attempt at theoretically unbreakable encryption? Thanks $\endgroup$
    – J Presper Eckert
    Commented Mar 8, 2016 at 17:10
  • $\begingroup$ SAF Santos: Understood. Have some time, don't mind exploring the trail. Understand key management issue. In this scenario, however, small recipient group, frequent physical interaction (thus large keys, large cipher streams can be exchanged via USB, or transmitted via email, drop box, etc. in a large stream of otherwise unrelated and open standard comm. There is truly no cost to transmission time, stream length, encryption/decryption time. Mr. Santos, what I'm finding, as a crypto amateur is none of OTP warnings seem to matter. What am I missing? Thank you for your time. $\endgroup$
    – J Presper Eckert
    Commented Mar 8, 2016 at 17:14

2 Answers 2

Reset to default
1
$\begingroup$

Ignoring concerns about missing integrity and authentication verification, here is why:

Suppose that the key you used to generate your keystream from your CSPRNG is shorter than your plaintext; if it isn't, you may as well use the one-time pad. Then I know from the pigeonhole principle that there will be some (many, actually) keystreams that will never be generated. Furthermore, I can enumerate these keystreams by simply going through every key (your plaintext has finite length, so there are only finitely many keys I have to check).

Therefore given any ciphertext, I can infer that there are many plaintexts that can never encrypt to this ciphertext, regardless of the key you picked. I have derived knowledge* about the plaintext from the ciphertext alone, therefore your encryption scheme is not information-theoretically secure (what you call "theoretically unbreakable").

Did I mention I was an entity with unbounded (infinite) computational power? If you want truly unbreakable encryption, this is effectively equivalent to your ciphertext conveying zero information about the corresponding plaintext without knowledge of the key. It's a very high bar to set, and one that is virtually useless in the real world, which is why we are perfectly okay with AES and the like.

You cannot cheat information theory by stretching your keys through deterministic processes. You cannot cheat information theory through elaborate encryption schemes involving multiple encryption passes with different keys and liberal sprinkling of hash functions and CSPRNG's - an unbounded adversary will see right through it, unraveling whatever layers of convoluted encryption you have going on, until it all eventually boils down to how much information your ciphertext has, which is itself fundamentally lower-bounded by how long your key is.

Information is given, not created, and your cipher's security is measured in terms of how much computation it takes to extract information out of the ciphertext without the key. If it carries no information, there is nothing to be extracted, and you have information-theoretical security.

* the length of the plaintext is not generally considered "knowledge" as it is more metadata than anything else; it cannot really be relied on as you can always pad your plaintext to a fixed length and communicate through a prearranged dictionary of fixed-length symbols.

Improve this answer
$\endgroup$
9
  • $\begingroup$ Thomas: thank you so much for your thoughtful answer. My CSPRNG data set of rnds comes from atmospheric noise -- nothing deterministic. Key length programmatically guaranteed to be as long as plaintext. Key file marked for decryption only after each encryption (no key reuse possible). There is virtually no overhead to encrypt/decrypt any message of any length, so there would be zero, rather than 'many' "key streams never generated". I can get 10^7 CS rnds a day for free. So key streams or plaintext size is not an issue. $\endgroup$
    – J Presper Eckert
    Commented Mar 8, 2016 at 17:23
  • $\begingroup$ Thomas: to continue. If the rnds are crypto secure then my plaintext 'a' can be encrypted to a ciphertext 'b', 'z', 'S', '$', etc. So this is the point where I struggle. Your domain expertise is manifest. But I don't see how, with what I've described, you can "infer ... many plaintext that can never encrypt to this cipher text". I respectfully suggest that ciphertext I generate can yield NO clue as to the corresponding plaintext. What Mr. Vernam created that I implemented with very straightforward file I/O and some VERY straightforward data manipulation. $\endgroup$
    – J Presper Eckert
    Commented Mar 8, 2016 at 17:33
  • $\begingroup$ Thomas: It's the key length and CS rnds, not my great skill;. That's why I persist in asking about this. It looks to my untrained eye as if I've done all the things required to answer all the objections of crypto pros to using a true OTP, Vernam, stream cipher. It seems as if it should work against your unbounded computational power. No problem is intractable. OK. "&&&&". (as long as you like). What's the plaintext? What's the key? With access to neither, how can you infer anything about either? $\endgroup$
    – J Presper Eckert
    Commented Mar 8, 2016 at 17:34
  • $\begingroup$ With what I've outlined, I assert I've met the zero info conveyance bar by reading some things, writing some simple code. Please help me understand what I'm missing. I find this subject very interesting, nothing more. Really eager to have an email exchange with you. I'm verbose or there's a lot to discuss. Love to chat further if you're open to that. Thanks for your time other way. Cheers, jpe $\endgroup$
    – J Presper Eckert
    Commented Mar 8, 2016 at 17:35
  • $\begingroup$ @JPresperEckert Usually a CSPRNG means a deterministic algorithm that takes a small cryptographically secure seed as an input and returns a stream of pseudorandom bits. Are you saying your "CSPRNG" has no seed but returns truly random bits through atmospheric noise or whatever? $\endgroup$
    – Thomas
    Commented Mar 8, 2016 at 18:40
0
$\begingroup$

Besides what @Fleep wrote in his comment, without integrity protection for the ciphertext, you are still very vulnerable to a bunch of attacks based on ciphertext manipulation.

And I'm not saying that's all possible problems with your scheme because one can never know for sure :/

Improve this answer
$\endgroup$
1
  • $\begingroup$ Roman: I'm a programmer without very much cryptography background. What do you mean by 'integrity protection for the ciphertext'? Hiding it with steganography, plaintext &/or ciphertext padding? Some author authentication hash with or in the message? I'm new to this, obviously. Just asking people with more expertise than I. I've answered, i think, the preceding objections/warnings/concerns. My stream cipher uses CSRNG keys as long as plaintext, never reused. Thanks for your time. $\endgroup$
    – J Presper Eckert
    Commented Mar 8, 2016 at 17:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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