A beginner's idea about cryptography

WDPEjoe

I know this subject doesn't necessarily pertain to PHP in particular, but this is the only forum I regularly read and I trust the people here intellectually (mostly the people who are moderators, which is why I posted this here). With that said, I'm in no rush for responses (I'm busy too) so read this at your leisure (or not at all).

I have been reading through as much as I can about cryptography in the last two months since I realed how vital a component it is to PHP & web-based applications in general. I'm not keen to the mathematics, but I do have a pretty solid grip on the ideas.

Specifically, I've been thinking about one-time pads lately. I don't know if this idea has been implemented anywhere, but here's what I've been thinking:

There are reasonably secure methods to transport an initial pad to the client browser during login. The server and the client would both store the pad, and the next one to make contact either way would first "randomly" generate a new pad (I know the limitations discussions that follow any use of the word random), store it locally, tack it on to the information being sent, then encrypt it using the initial pad sent by the server.

The server would then save the new pad, and then whoever would initiate the contact would do the same thing.

This is far too simple. It is either
(a) Theoretically flawed
(b) Implementationally (?) flawed
(c) Already in existence

Someone please enlighten me.

Piranha

I can see three problems with that way to solve the problem.

You have to run a program on the client computer to generate the new pad. I for one would not like to install a program "just" to do that. I don't think it is possible to do that with the browser as it is now.
The user have to connect with the same computer all the time. If the user change the security he/she won't get the security.
You say that "there are reasonably secure methods to transport an initial pad". Following that statement someone that listens to the traffic can crack that first pad. If that is cracked then it is easy to crack the following, the result is that it probably won't be more secure than using any of those "resonably secure methods".

These are my thoughts. I am not sure if everything is totally correct, you are probably able to come to a conclusion about this yourself since you probably have read more about security than I have.

MarkR

WDPEjoe wrote:
There are reasonably secure methods to transport an initial pad to the client browser during login.

Would you care to elaborate?

A one-time pad's inherent weakness is that the pad needs to be got to both ends.

How exactly do you propose a "reasonably secure method" of transporting several one-time pads to the client?

Bear in mind that most crypto problems already have well tested solutions- these are of course not guaranteed to be secure, but are more likely to be than one I made up on the back of an envelope.

Mark

laserlight

There are reasonably secure methods to transport an initial pad to the client browser during login.

Ah, but if such a secure channel exists, then it can be used to send the message itself without the need of a one time pad.

The server and the client would both store the pad, and the next one to make contact either way would first "randomly" generate a new pad (I know the limitations discussions that follow any use of the word random), store it locally, tack it on to the information being sent, then encrypt it using the initial pad sent by the server.

Suppose the initial pad is n bits long. Suppose also the data to be encrypted (the message) is m-bits long, where m <= n. Now, what should be the length of the new pad to be generated? It cannot be more than (n-m) bits long, otherwise some portion of the initial pad must be reused, breaking the security of the one time pad. But if it is (n-m) bits long, then it is redundant, since we might as well use the remaining (n-m) bits of the initial pad. So, the only case where generating a new pad is useful is when the message is n bits long. But then we end up generating a pad that is 0 bits long, and thus have no new pad at all.

WDPEjoe

First: Mark, I am not proposing a new encryption scheme. I clearly labeled myself a beginner in the post's title, and this is an exercise to see where my understanding is flawed.

Second: Mark, my idea was that the next pad to be used could be tacked on to the information before it is encrypted and sent across an insecure channel. It could then be stored on both machines (but never have been sent across the channel plaintext). So, after the initial exchange (over SSL, or whatever you'd like), the pads are exchanged in encrypted messages one at a time, right before they are used.

Third: laser, Let's say for the sake of discussion that we know the message + new pad (m bits long) is known to always be less than the current pad (n bits long). I don't see the issue with m > n as you would just use the first m bits of the pad to decrypt it (as would the server).

laserlight

Second: Mark, my idea was that the next pad to be used could be tacked on to the information before it is encrypted and sent across an insecure channel. It could then be stored on both machines (but never have been sent across the channel plaintext). So, after the initial exchange (over SSL, or whatever you'd like), the pads are exchanged in encrypted messages one at a time, right before they are used.

Third: laser, Let's say for the sake of discussion that we know the message + new pad (m bits long) is known to always be less than the current pad (n bits long). I don't see the issue with m > n as you would just use the first m bits of the pad to decrypt it (as would the server).

One of the important points to remember here is that you cannot encrypt more plaintext than there is pad data. Let's suppose m = 2n/3, and that the message length is the same as the new pad length (i.e., n/3 bits long). On the next iteration of this protocol, the pad length is now n/3 bits long, so the new message length (using the same proportions) is n/9. It is easy to see that the pad length (and hence maximum message length) will become smaller and smaller on each run of the protocol (in a geometric progression).

But there's more. Remember, the initial pad consists of random bits, as does your newly generated pad. So, it does not make sense to use the initial pad to encrypt the new pad. The parties involved might as well agree to use the portion of the initial pad that is unused.

MarkR

I still don't understand how this adds anything to the method that you use to send the initial pad.

Whatever (presumably secure) method you used to send the initial pad, could have been used to send the message instead. Doing what you propose does not add security as it could easily be reversed if the channel could be intercepted (including the initial pad).

I am probably misunderstanding it, but I don't see how this method does anything other than:
- Obfuscate the data
- Add extra data to be transferred, making the stream larger

Mark