From: Yakov Shafranovich <research(_at_)solidmatrix(_dot_)com>
...
Instead of storing the actual email address in the database, we might store
a one-way hash of it, lets say MD5. When emails are sent and received, the
sender's email address is hashed and compared against the database. This
way if anyone ends up wanting to use the database, it would be impossible
since there will be no email addresses in it. Of course it would still be
possible to check a specific email address against or use some form of a
dictionary attack, ...
Which implies that in the cases that matter, nothing is hidden. Dictionary
attacks are easy when you know what you're looking for. This is one
reason why the DCC procotol does not include a checksum for the target.
That's not a complete solution, but it's not as bad as the C/R case
where the database would consist of a recipient and a set of senders.
It seems me that the right answer for a C/R system is to treat the
data as equally sensitive as users' addressbooks. Do not use
crypto-hashes, lest you tempt the unthinking or salescritters into
claiming that the data is not sensitive. Never unthinkingly trust
third parties with the C/R database.
...
And last, another concern that has been bothering me with C/R, is the
possible death of anonymous remailers with such system. ...
Such concerns assume that C/R systems might be used by a majority of
users. Doesn't experience with existing C/R systems show that is unlike?
One of the saving graces of a C/R system is that it does not need to
be deployed over most of the Internet before it has any effect. Don't
waste that advantage by treating it as if it were or could be the final
solution against spam.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg