On Digital Cash-like Payment Systems
Travis H.
solinym at gmail.com
Mon Nov 14 07:16:55 EST 2005
> 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 majordomo at metzdowd.com
More information about the cryptography
mailing list