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