-3
$\begingroup$

I'm a computer programmer and I'm working on a truly unbreakable cypher and I keep going back to a book cypher (each letter of the message is referenced by a page,row,and column number in a random book where both the sender and receiver have identical copies.) In my update we use data files and auto lookup. here is my version:

Step 1) create a book

  • generate a "book" of 5,000,000,000 characters writing the characters randomly. (5 gb)

Step 2) the spys each go there own way

  • both sender and receiver have a copy of the file, but its exists nowhere else. (think 2 raspberry pi's that have never been on the internet)

Step 3) encrypter

 - for each letter of message, pick a random number from 1- 4,500,000,000
 - from that index find a matching character looking forward in the file
 - write to the encrypted file an unsigned 64-bit integer of the sum of 
   the index plus some random large number say for example,715073703555645

Step 4) decrypter

  -reverse the encrypter easy enough for a software program. 

If that isn't enough take another random large number, say for example: 36854775 and write that many characters characters out in random before and after the message to the encrypted file.

So how exactly can this be broken?

$\endgroup$
6
  • $\begingroup$ "write to the encrypted file an unsigned 64-bit integer of the sum of the index plus some random large number say for example,715073703555645"; how is the decryptor supposed to know the random large number you've just added? $\endgroup$
    – poncho
    Mar 2, 2023 at 21:31
  • $\begingroup$ Apart from poncho's question, which requires clarification indeed, note that block ciphers are similar in every respect to book ciphers but there's no need to generate the entire book in order to use them. In other words, a block cipher, given a key and plaintext/ciphertext which you may as well call "page number, row number, column number" can generate both the corresponding ciphertext (for plaintext) or plaintext (for ciphertext) without precomputing the entire book. It's like a capsule sized code book :) $\endgroup$
    – Amit
    Mar 2, 2023 at 22:27
  • $\begingroup$ "how is the decryptor supposed to know the random large number you've just added? " the large number is fixed with both the encrypter and decrypter. the decrypter reads the 64-bit unsigned integer and subtracts the base number. then the decrypter can look at the character at that address in the file. $\endgroup$ Mar 3, 2023 at 0:47
  • $\begingroup$ Amit, I don't understand "s, a block cipher, given a key and plaintext/ciphertext which you may as well call "page number, row number, column number" can generate both the corresponding ciphertext (for plaintext) or plaintext (for ciphertext) without precomputing the entire book. " If all it takes is the key and the plaintext/cihertext, what is guaranteeing that some other program can't repeat the decrypt? $\endgroup$ Mar 3, 2023 at 0:52
  • $\begingroup$ The review of such cryptographic designs is off-topic. $\endgroup$
    – fgrieu
    Mar 3, 2023 at 6:56

1 Answer 1

1
$\begingroup$

From OP's comment:

If all it takes is the key and the plaintext/cihertext, what is guaranteeing that some other program can't repeat the decrypt?

Because the key is long enough, just long enough to make brutal-force attack impossible.

There are some basic models against which a cipher algorithm must be secure, and yours are clearly isn't.

In fact, you've been using "truely unbreakable ciphers" all the time, when you browse a HTTPS website. These websites use TLS or QUIC protocols, which use ciphers to protect both the secrecy and integrity of data exchanged between your computer and the server.

3 of the most popular "truely unbreakable ciphers" are:

  • ChaCha20-Poly1305: a software-friendly design.
  • GCM-AES: a hardware-friendly design.
  • CCM-AES: used most-often in WiFi encryption

A short critique of the OP's proposed cipher.

  1. The codebook is 5GB in size, no practical key exchange algorithm can support that (ECDH are typically no bigger than ~500 bits, finite-field DH can go bigger than that, but isn't in any capacity information-theoretically secure).

  2. How are you supposed to generate that big a key? How are you supposed to pick a character in that codebook? Why can't we use such technique to make a stream-cipher (which is much more efficient than carrying a 5GB code book around)?

$\endgroup$

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