Those integers are way way larger than the modulus of the alphabet, or even the modulus of ASCII.

I [think I] understand that the prime modulus must be huge in the context of creating keys to be used in ciphers like AES, but what about in the context of having different random keys for each character in OTP?

For example, let's say that my messages only feature letters a through z, and I have a smaller modulus:

p = 27
g = 3
userPrivateKeys = [9,12,0,23,7,8,4,7,15,24]

Our algorithm would be:

2^a mod 27

or in Javascript...

Math.pow(2, a) % 27

And we'll have generated a list of public keys:

userPublicKeys = [26,19,1,5,20,13,16,20,17,10]

That's way more manageable.

So in this context, is there a problem with the prime modulus being so small?

As far as I can tell, the only way to break this is through exhaustive search; since OTP cryptext contains no information about the original message, exhaustive search would be infeasible. I have read of other possible ways of breaking this and DH in general, but usually I don't understand them or they either depend on one of the secrets being known.

Yes, since one can solve the discrete logarithm problem to go from userPublicKeys to userPrivateKeys. $\hspace{.31 in}$ The ciphertext is irrelevant to that attack, since that attack only uses the key exchange data. $\:$ You're also missing that mod(g^a,p) needs to be computed exactly, rather than via Math.pow(g, a) % p. $\hspace{.57 in}$
–
Ricky DemerDec 10 '13 at 4:57

Okay, I read a little more on the discrete logarithm problem. (I swear I couldn't find much specific on it last night. Haha) So would I be correct in saying that the discrete logarithm problem can be solved easily when the prime modulus is small but it becomes increasingly difficult to solve the larger the prime gets?
–
user10800Dec 10 '13 at 5:15

1 Answer
1

Well, for one thing, you are not using a "One Time Pad". A "One Time Pad" means, by definition, that someone generates a pad of numbers using true randomness (and not algorithmicly), and that no potential adversary has any information on what that pad may contain. Then, that pad is given to both the sender and the receiver, and then the sender uses it to disguise the plaintext, in a way that the receiver (with the pad) can recover the plaintext, but the adversary, who doesn't have the pad, gets no information about the plaintext (because with the ciphertext and any potential plaintext, there is a possible pad that makes that possible, and the adversary has no way of deciding which potential pad is more likely.

Instead, you are performing a series of Diffie-Hellman operations to generate shared secrets, and then using those shared secrets to perform a stream encryption.

Here is why this is distinction is important; you state:

the only way to break this is through exhaustive search; since OTP cryptext contains no information about the original message

This would indeed be true, if you were using an OTP; the attacker would literally have no information beyond the ciphertext, and the ciphertext would indeed reveal no information about the plaintext. However, the ciphertext is not the only thing the sender and receiver are exchanging, you mention previously that:

the user and the server exchange their public keys

That is, there is information available to the attacker in addition to the ciphertext that he can use. That is, instead of being informationally secure (which OTP is), you also hope that the attacker cannot use the public keys to recover the shared secret (pads), that is, you hope that the problem of recovering the shared secret is just too difficult for the attacker. In other words, you hope that you are computationally secure.

Here, in that light, when you ask:

is there a problem with the prime modulus being so small?

The question you are asking is "is Diffie-Hellman computationally secure, even if the modulus is tiny". The answer to that is "no, it is not". For MODP groups (which are the groups you are using), it appears that DH can be broken unless the modulus is at least 800 bits (actually, attacks against modulii that size haven't actually been demonstrated, but there have been attacks against related primitives, and we believe those attacks can be converted into attacks against Diffie-Hellman).

There are other groups that can be made smaller and still are believed to be secure (for example, an elliptic curve group is probably pretty secure even if the curve is only 200 bits or so); however you won't get anywhere close to "an ASCII value".

When we use Diffie-Hellman like this, what we generally do is perform a single Diffie-Hellman operation to generate a single (large) shared secret, and then give that shared secret to a Key Derivation Function; the output of that KDF may be then presented to a Stream Cipher, whose output is then used to actually encrypt the data

@RickyDemer: thanks; if you go through my answers, you'll find that I often think one word, but type something else...
–
ponchoDec 10 '13 at 5:21

Since OTP requires perfect informational secrecy by definition, what would you suggest I refer to this scheme as? Just a "stream cipher"? I referred to it as a One Time Pad because, aside from the fact that information about they keys is leaked, it seems to be the same idea otherwise. Couldn't using a key derivation function open up my system to exhaustive search? Wouldn't there still be an advantage to each message character having its own random shift? In case I didn't mention(and in case it's important), only truly random numbers are being used.
–
user10800Dec 10 '13 at 5:22

@user10800: well, I'm not sure what you should call it (stream cipher really doesn't apply either, come to think of it; it uses inputs from both sides; it appears to be closest to El Gammal, but it's not that either). The term OTP doesn't apply, because the one point that you're missing is a very important point about OTPs. As for exhaustive search, well, you're secure computationally, and so the correct protection against exhaustive search is to make it computationally to difficult to consider. As for each character getting its own random shift, we have better ways to protect plaintext.
–
ponchoDec 10 '13 at 23:44