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