> Don't ever encrypt the same message twice that way, or you're likely to > fall to a common modulus attack, I believe.
Looks like it (common modulus attack involves same n, different (e,d) pairs). However, you're likely to be picking a random symmetric key as the "message", and Schneier even suggests picking a random r in Z_n and encrypting hash(r) as the symmetric key. More generally, I wonder about salting all operations to prevent using the same value more than once. It seems like it's generally a bad idea to reuse values, as a heuristic, and applying some kind of uniquification operation to everything, just as it's a good idea to pad/frame values in such a way that the output of one stage cannot be used in another stage of the same protocol. > > Since I'm on the topic, does doing exponentiation in a finite field > > make taking discrete logarithms more difficult (I suspect so), and if > > so, by how much? > > This doesn't make sense. The discrete log operation is the inverse of > exponentiation. Doing exponentiation is a prerequisite for even > considering discrete log operations. Hence it cannot make them "more > difficult". What I really meant was, if it wasn't computed in a finite field, how difficult would it be to compute the logarithm? I'm just curious about how much work factor is involved in reducing modulo n. I also wonder about some of the implications of choosing a message or exponent such that not enough reductions take place during exponentiation. > I'm not sure conventional covert-channel analysis is going to be that > useful here, because the bandwidths we are looking at in this attack > model are so much greater (kilobytes to megabytes per second). Well, it depends on how you define the attack, which wasn't defined. If the attack is to smuggle out a key using a covert channel, it may apply. If the attack is to download the key on a conventional network, it wouldn't make much difference. Unless, of course, you're auditing network flows over a certain size or lasting a certain amount of time. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]