# can you update a one-time pad, over one-time pad encryption (compressed)?

This might well be a silly question, but at the moment I've not thought of a reason it doesn't work.

As I think is generally known, you should never re-use a one-time pad. But compression allows you to transmit something larger than the number of bytes used in transmission...

I'm not intending to / have no reason to do this but thought it was an interesting idle thought wondering why you can't:

• establish initial one-time pads securely with someone.
• communicate using the pads, and when it gets near the end, transmit a knew (compressed) one-time pad, which you both subsequently use.

(I realise the ratio of data vs pads in your throughput might be pretty terrible).

I'm assuming someone strong on maths might be able to explain that if the algorithm is known it might be possible to break it because in a way data is being 'reused', though in an encrypted, compressed form the first time, as the key the second.

If the security does degrade, at what point/how much? (Assuming neither ends have the conversation have been compromised).

edit: thanks for looking guys, I forgot that random data is hard to compress; question answered.

-
Why do you think OTP is secure/insecure depending on the content of the message Alice wants to send to BoB? – dfc Mar 28 '14 at 0:01
... I'm not sure I follow? I'm aware that repeated pads will throw the entropy off, so I'm open to the concept that transmitting pads (even compressed) might do the same. Is that what you mean? – pacifist Mar 28 '14 at 0:05
Since the OTP is supposed to be crytographically secure random data, it should not be compressible at all. – Johnny Mar 28 '14 at 0:08
Are we assuming the OTP is securely implemented, transferred and used? – dfc Mar 28 '14 at 0:09
It is also worth pointing out that "compression allows you to transmit something larger than the number of bytes used in transmission" is not true for random data. Try `dd if=/dev/urandom of=rand bs=1024 count=10000 ; xz -k rand ; du -b rand rand.xz` – dfc Mar 28 '14 at 0:14