nym-0.2 released (fwd)
cyphrpunk at gmail.com
Sun Oct 2 12:12:18 EDT 2005
A few comments on the implementation details of
1. Limting token requests by IP doesn't work in today's internet. Most
customers have dynamic IPs. Either they won't be able to get tokens,
because someone else has already gotten one using their temporary IP,
or they will be able to get multiple ones by rotating among available
IPs. It may seem that IP filtering is expedient for demo purposes, but
actually that is not true, as it prevents interested parties from
trying out your server more than once, such as to do experimental
hacking on the token-requesting code.
I suggest a proof of work system a la hashcash. You don't have to use
that directly, just require the token request to be accompanied by a
value whose sha1 hash starts with say 32 bits of zeros (and record
those to avoid reuse).
2. The token reuse detection in signcert.cgi is flawed. Leading zeros
can be added to r which will cause it to miss the saved value in the
database, while still producing the same rbinary value and so allowing
a token to be reused arbitrarily many times.
3. signer.cgi attempts to test that the value being signed is > 2^512.
This test is ineffective because the client is blinding his values. He
can get a signature on, say, the value 2, and you can't stop him.
4. Your token construction, sign(sha1(r)), is weak. sha1(r) is only
160 bits which could allow a smooth-value attack. This involves
getting signatures on all the small primes up to some limit k, then
looking for an r such that sha1(r) factors over those small primes
(i.e. is k-smooth). For k = 2^14 this requires getting less than 2000
signatures on small primes, and then approximately one in 2^40 160-bit
values will be smooth. With a few thousand more signatures the work
value drops even lower.
A simple solution is to do slightly more complex padding. For example,
concatenate sha1(0||r) || sha1(1||r) || sha1(2||r) || ... until it is
the size of the modulus. Such values will have essentially zero
probability of being smooth and so the attack does not work.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography