[hashcash] Re: OmniMix with recipient related Hashcash

  • From: Christian Danner <hashcash_list@xxxxxxxxxxxxx>
  • To: hashcash@xxxxxxxxxxxxx
  • Date: Fri, 08 Dec 2006 12:43:01 +0100

Hello Eric,
hello Adam!

Eric S. Johansson wrote:

> The next stage will be PR.  When I 
>finish up twopenny blue, I'm planning on writing up and sending out a 
>press release via one of the free channels or one of the cheap channels. 
>  I'm going to also include references to all the other folks that are 
>compatible to make it look like a huge movement.  :-)

That would be great. Don't forget to spread some hints for a fast Spam
Assassin setup.

>> Above all OmniMix is a privacy tool. So if you only run an IMAP client
>> and don't rule over the server your privacy is irretrievably gone.
>> OTOH if you run both it may be possible to employ OmniMix at the
>> outbound side and control it with header directives, one of which now
>> is a Hashcash activation switch ('O-HashcashRecipient-Active: Yes)'.
>> But this would imply all the problems that come with server side
>> minting.
>
>I assume this isn't a problem with pop three?

Right, with SMTP/POP3 it's a transparent solution without the
necessity of any data buffering within OmniMix.

>  It seems to me that if 
>you leave the traffic encrypted or what ever and only decrypt on 
>read/display, IMAP shouldn't be a problem even if the server is not 
>under your control.

You wouldn't like the implications of an interception of the IMAP C/S
communication.

When sending a message OmniMix makes equally looking 20kB messages
destined for the first remailer out of them, which are multi-encrypted
for the remailers in the chain. So for later inspections they're
totally worthless, if they actually make it to the 'Sent' box of your
account and aren't directly delivered to some hidden Tor service by
OM.

Messages sent to you as the anonymous recipient (account holder at
some nym server) are usually delivered by posting them to a newsgroup,
where OM picks them up automatically on a POP3 request. I have no idea
how to inject those data into a C/S conversation in order to achieve a
(somehow encrypted) storage at the IMAP server and deliver it to the
client at the same time.

>  As a friend pointed out to me, I accidentally 
>solved a big chunk of the mailing list problem with the hybrid system I 
>had developed.  The first message to a new user gets a stamp.  Then the 
>logos back to normal.  Jonathan pointed out that if we implemented the 
>opportunistic signature technique than mailing list could sign their 
>messages which would make it easier for users to not get spoofed with a 
>by address white list.
>
>Yes.  I know.  This is not part of the simple hash cache implementation. 
>  :-)

As Adam also described correctly. Thanks for his annotations.

[interesting strategic implementation considerations snipped]

>Seriously, there has been a huge psychological barrier to hash cash over 
>the years.  The biggest objection has been the stamp on every message 
>model which is what drove me to the level of complexity I am currently 
>implementing.

But that's the basic principle of Hashcash, which can't be 'cured'
from within itself, and with a distibuted client-side calculation it
even doesn't hurt. I'd inform admins of how to make Spam Assassin
evaluate Hashcash and make the benefit of some seconds of computation
time per message clear to the users.

>> Please correct me if I'm wrong, but I see the (pure) principle of
>> Hashcash in spending a certain amount of computation time in order to
>> supply evidence for the seriousness of my message. If my device (PDA
>> etc.) doesn't allow me to support such a strategy, then my mail has to
>> be better in other areas to pass spam filters. Hashcash isn't a
>> cure-all for spam, however it provides a valuable additional
>> characteristic to base a filtering decision on.
>
>Or... my argument for low-power devices is "let the server do it".  It's 
>totally appropriate and is a good example of how one can assign a value 
>to a proof of work stamp.  How much is it worth to you to generate a 
>stamp that will guarantee your message will be delivered to a 
>destination mailbox?  Again this is another reason for the one stamp 
>friends list.  Once the PDA has sent a message and you've paid for that 
>stamp via some other resource, now the PDA is free to send as many 
>messages to that address as you can create.

Maybe with an option to decrease the value message by message until
another Hashcash equipped mail is sent, which restricts abuse and
should work well in an environment where PDAs and desktop systems are
used alternately.

>With regards to Spam assassin, I think it's a wonderful that it's been 
>included.  I am sad however that it does not default on.  But as I've 
>said before, I have tried for years to get others to turn on stamp 
>systems and the basic argument circles around the drain this way:
>
>Why should I filter for stamps if nobody's generating them.
>
>Why should I generate stamps if nobody's filtering for them.
>
>Why should I ask my users to sit there and wait for minutes to generate 
>stamps when it's useless because nobody's filtering for them.

That's no valid argument if you don't dictate the size of the stamps
and even a low-bits token, minted within seconds, implies some value.

>generating stamps is going to break my server if I generate them for 
>every message.

Therefore client side creation.

>and then there's the usual angry retort about to hell with you for 
>assuming that I'm going to burn cycles for your stupid stamp.

ACK, better use them for a spectacular screen saver ;-)

>Seriously, there is significant psychological resistance to creating 
>stamps.  About half of the resistance goes away if there is some sort of 
>throttle on stamp generation.  The white list technique is one of the 
>better throttling techniques but I accept that is too complex for simple 
>systems.  That's why I think the DNS technique is a good first step. 
>The model I've worked out for DNS doesn't even require a server telling 
>you how much per user.  All it is a static record describing something 
>about the recipient site and the stamp size required.

IMHO the best _first_ step is to avoid all kinds of infrastructural
requirements.

>Okay.  We are basically on the same page.

Right. It's a mighty instrument. But better take the first step before
the second ;-)

Kind regards

Christian
-- 
OmniMix .. protect your privacy
http://www.danner-net.de/om.htm

Other related posts: