Despite the fact that it passes 3 times “in the clear,” the Diffie-Hellman key exchange is mathematically impossible to reverse engineer. Nevertheless, it becomes necessary to force any possible table look-up to become excessively unwieldy, before the key exchange is satisfactorily secure.
Most computer code languages have a random function that can be salted with a start point, such that the built-in random number generator (PRNG) delivers random numbers that follow a repeatable progression. Code based on a seeded PRNG would exhibit repeatable randomness, without being totally random. Note: compiling the same source code with another compiler would not necessarily result in the same PRNG. This could be good or bad, depending on your point of view.
While exchanging a salt by a potentially intercepted voice or IM link would be abstractly subject to duplicating the entire PRNG, the value can be employed to improve the key exchange in the same way that the Caesar Shift improved the substitution cipher.
The expedient of providing a list of salts in a drop down menu of the “form,” would serve to implement the procedure, and it could be augmented by XORing the salt with the date.
This suggested protocol involves building the key exchange around a base prime number, but calls for the base prime number to be chosen (based on the n’th value chosen from a PRNG when seeded with the salt) from a dataset of pre-generated primes, placed in a data statement.
A ten digit prime base suffices to generate a ten digit key from each secret number choice, and the total count of possible prime numbers in the ten digit range would daunt any thought of building exhaustive look-up tables.
If the proverbial “Bob,” and “Alice,” go through the added step of exchanging keys twice (or more,) it becomes possible to specify a 20 digit key, adding to the difficulties of the brute force attack against the resulting key.
While it must be understood that any key derived this way would be less secure than an exchange based on a 20 digit base number, (in fact being equal to two instances of a 10 digit key,) it is possible to add a proprietary procedure, whereby the end users must either concatenate the two in an agreed order, or multiply the two together, for the final key.