1
$\begingroup$

here is an idea that I feel has some big flaw I can't put my finger on.

The scenario is: Alice will go overseas for 5 days and will hopefully retrieve some information and send it back to Bob. She does not want to let anyone listening to know what day she got the information. She is taking with her a one time pad the size of the information, and a hardware random number generator.

The solution I thought of was:

Alice and Bob at home
Alice creates new key(key1) > Bob (key1)

Alice travels to Elbonia
Alice creates new key (key2) XOR key1 > Bob (key2)
Alice creates new key (key3) XOR key2 > Bob (key3)
Alice creates msg + padding (msg) XOR key3 > Bob (msg)
Alice creates new (rand) > Bob (rand)
Alice creates new (rand) > Bob (rand)
Alice travels home

Is this system any better or worse than just sending the encrypted message the day she receives the information, and pure random data on the other days?

Improve this question
$\endgroup$
  • $\begingroup$ What do the usage of key2 and key3 gain you as opposed to just using key3? $\endgroup$ – SEJPM♦ May 18 '17 at 12:15
  • $\begingroup$ Bob doesnt have key3, until he decrypts the 2nd days message. He does this with the decrypted 1st days message, he decrypts that with the original key they shared in person. $\endgroup$ – daniel May 18 '17 at 12:41
  • $\begingroup$ But why can't you just send noise on days 1 and 2? $\endgroup$ – SEJPM♦ May 18 '17 at 16:01
  • $\begingroup$ One of the big flaws is the question itself unfortunately. What metadata exactly are you trying to conceal? Time of transmission of real message , length of message or number of messages? You add padding in your flow which suggests message length hiding but you highlight time of getting the message which isn't exactly the time of transmission... $\endgroup$ – Paul Uszak May 18 '17 at 19:47
  • 1
    $\begingroup$ @PaulUszak I am trying to conceal which day the information is sent. I threw padding in there to imply the message Alice sent was always the same size. $\endgroup$ – daniel May 18 '17 at 21:17
2
$\begingroup$

Basically that's a one time pad variant where each day a cryptogram is sent, consisting of one between

  • on days before the actual message is sent, a new random pad replacing the previous random pad (of same size as the original), encrypted by XOR with the current random pad;
  • on a certain day, the message to be sent (padded to the pad size) encrypted by XOR with the current random pad;
  • random (of the pad size) on subsequent days.

That allows to send a single message. As is, the receiver has to know in advance or figure out on which day the message was sent, but the later is easy for practical messages.

That works; assuming all random bits generated are perfectly independent and unbiased, it insures the same unconditional security as the one pad, and meets the stated security objective of concealing on which day the information is sent. The quality of the generator is paramount: notice for example that a mere distinguishing attack allows to find on which day the actual message is sent.

Form a practical standpoint, the proposed system has a serious operational drawback compared to sending random on every day the message is not sent: if the cryptogram from any day before the actual message is sent gets lost (or is garbled), the message can not be deciphered (or is garbled).

I do not see any advantage, under the hypothesis that all random bits generated are perfectly independent and unbiased.

Improve this answer
$\endgroup$
  • $\begingroup$ On the operational drawback point, I was thinking the lower layers or process would take care of re transmission and error correction: as in sending a zipped file in an email each day, with an annoying read receipt. $\endgroup$ – daniel May 19 '17 at 9:16
  • $\begingroup$ Also on protecting from any man in the middle attacks (message tampering, lost messages) I could put a header somewhere in the message that read "everything is fine, nothing is broken, this is keyXXX" but it would chip away at the key length each time, and the header would have to be sufficiently long to not likely appear in the key by accident. $\endgroup$ – daniel May 19 '17 at 9:24
1
$\begingroup$

It's worse, both pragmatically and historically. You're falling into the all too common but very enticing attempt to improve on the venerable one time pad. History has repeatedly proven the integrity of the technique as used. The key material was never extended in the field over the transmission channel. People have been executed transporting key material. If a pad could reliably be transmitted over the same communication channel as the cipher text, they could have stayed at home drinking tea.

You might mathematically be able to extend, but when you start performing all the xors with this bit and that bit, you risk pad reuse and exposure. If your team has access to a hardware random number generator, use it as intended and supply Alice with sufficient key material for authentic and dummy messages. Allow for padding of you wish. Then send authentic and dummy messages at random times or at regular times to disguise the real transmission.

Hiding the date of genuine transmission is called masking, and the guys at security.SE might be able to say more about it and broader traffic analysis. This is serious terrorist and paedophile stuff so look towards military signals intelligence. Understandably, not a lot of contemporary material out there (excluding amateur academic stuff) but here's a fun 1948 document you can start with.

And yes, it's needlessly complicated.

Improve this answer
$\endgroup$
  • 1
    $\begingroup$ But I'm not extending the key material, If the first key was 10mb, then the information sent can not be more than 10mb. The three parts to why is, 1. I want to encrpyt the data 2. I want to mask the channel 3. I want to make sure an old key no longer works. My main question was show me how this does not preserve perfect secrecy. $\endgroup$ – daniel May 19 '17 at 7:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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