Re: Current examples for creating keys, updating and getting freesites
Michael Pearce <michaelgpearce-/[email protected]> Sun, 17 Nov 2013 23:40:03 -0800 (PST)
| Newsgroups | gmane.network.freenet.technical |
|---|---|
| Message-ID | <[email protected]> |
--===============0845124784== Content-Type: multipart/alternative; boundary="1018116533-856279044-1384760403=:58388" --1018116533-856279044-1384760403=:58388 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable My plan is to also associate a messaging identity to a Bitcoin address with= a non-zero balance that the user owns (i.e. can sign with). =A0This should= help ensure that there is something closer to a person attached to the sen= der. =A0Nothing will be perfect in regards to spam, but i'm hopeful this wi= ll get me close enough.=0A=0AThanks a lot for the link to the Freemail spec= . =A0I'm sure i wouldn't have come across this on my own and gives a good u= se case of working with Freenet as a communication layer.=0A=0A=0A=0AOn Sat= urday, November 16, 2013 7:57 PM, Steve Dougherty <steve-kVTqj8yhOEv2eFz/[email protected]> wro= te:=0A =0AOn 11/12/2013 04:16 AM, Michael Pearce wrote:=0A> I just noticed.= .. the AntiSpamHash should also include the sender's=0A> identifier to avoi= d the sender using a nonce from a message already=0A> sent to the recipient= and avoiding calculating the AntiSpamHash.=0A=0AThat does seem like an imp= rovement, but one worry I have with=0Ashort-lived identities in general is = that a spammer needs only to=0Acompute more hashes faster to spam more effe= ctively. It's a balancing=0Aact between making identity establishment fast = enough to be useful and=0Ainvolving enough social forces / slowness to impa= ir spam.=0A=0A> On Tuesday, November 12, 2013 1:07 AM, Michael Pearce=0A> <= michaelgpearce-/[email protected]> wrote:=0A> =0A> Thanks for the response!=A0 All g= ood information.=A0 Its fun to think=0A> about how to build a system with t= he very specific constraints that=0A> Freenet imposes.=0A> =0A> I'm not bui= lding a messaging application per se, but users will need=0A> to communicat= e and most identities will not be very long-lived.=A0 This=0A> is leading m= e towards thinking I can get away with a single key to=0A> announce new mes= sages.=A0 I was also thinking about adding a Nonce to=0A> the message combi= ned with an expensive hashing algorithm (i.e.=0A> BCrypt) so spamming a use= r takes some work on the spammer's side.=0A=0AMay I ask what you're buildin= g? It will be easier to give more informed=0Aand specific suggestions with = that knowledge.=0A=0A> A sender would create a message similar to:=0A> =0A>= Sender <- my public identifier=0A> =0A> Recipient <- recipient's public id= entifer Nonce <- unique value to=0A> this recipient from the sender for thi= s message=0A> =0A> SenderSignature <- sender signs message with (recipient,= nonce) to=0A> ensure sender is who he says he is AntiSpamHash <- Bcrypt(re= cipient,=0A> nonce, minimum_rounds) to force some work on the sender=0A> = =0A> MessageBodyId <- location of signed/encrypted message body located at= =0A> a different Freenet key=0A> =0A> As a receiver checking for incoming m= essages, he only fetches the=0A> message body for messages that:=0A> =0A> *= Have himself as the recipient=0A> * Have a unique Nonce from the sender (n= o duplicates to avoid=0A>=A0 signature / anti-spam value stealing)=0A> * C= orrect signature at SenderSignature * Correct AntiSpamHash=0A> =0A> If all = of these match, the receiver will then retrieve the message=0A> body.=0A> = =0A> I think the above scheme will allow for looking at the shared key=0A> = pretty quickly, and a computationally expensive AntiSpamHash will=0A> disin= centivize large amounts of spam.=A0 Definitely not perfect but it=0A> may b= e good enough for my needs.=0A=0AThis is between individual users? This sou= nds a lot like Freemail's use=0Acase. Perhaps you could base your protocol = on that, or use Freemail as a=0Atransport? [0]=0A=0A=0ASteve=0A=0A[0] https= ://github.com/Thynix/Freemail/blob/spec/docs/spec/spec.tex=0A=0A=0A________= _______________________________________=0ATech mailing list=0ATech@freenetp= roject.org=0Ahttps://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech --1018116533-856279044-1384760403=:58388 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;fo= nt-size:10pt"><div>My plan is to also associate a messaging identity to a B= itcoin address with a non-zero balance that the user owns (i.e. can sign wi= th). This should help ensure that there is something closer to a pers= on attached to the sender. Nothing will be perfect in regards to spam= , but i'm hopeful this will get me close enough.</div><div><br></div><div s= tyle=3D"color: rgb(0, 0, 0); font-size: 13px; font-family: HelveticaNeue, '= Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-serif; background-= color: transparent; font-style: normal;">Thanks a lot for the link to the F= reemail spec. I'm sure i wouldn't have come across this on my own and= gives a good use case of working with Freenet as a communication layer.</d= iv><div class=3D"yahoo_quoted" style=3D"display: block;"> <br> <br> <div style=3D"font-family: HelveticaNeue, 'Helvetica Neue', Helvetica, Arial, '= Lucida Grande', sans-serif; font-size: 10pt;"> <div style=3D"font-family: H= elveticaNeue, 'Helvetica Neue', Helvetica, Arial, 'Lucida Grande', sans-ser= if; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2" face=3D"Arial"> O= n Saturday, November 16, 2013 7:57 PM, Steve Dougherty <steve@asksteved.= com> wrote:<br> </font> </div> <div class=3D"y_msg_container">On 11/12/= 2013 04:16 AM, Michael Pearce wrote:<br clear=3D"none">> I just noticed.= .. the AntiSpamHash should also include the sender's<br clear=3D"none">>= identifier to avoid the sender using a nonce from a message already<br cle= ar=3D"none">> sent to the recipient and avoiding calculating the AntiSpa= mHash.<br clear=3D"none"><br clear=3D"none">That does seem like an improvem= ent, but one worry I have with<br clear=3D"none">short-lived identities in = general is that a spammer needs only to<br clear=3D"none">compute more hash= es faster to spam more effectively. It's a balancing<br clear=3D"none">act between making id= entity establishment fast enough to be useful and<br clear=3D"none">involvi= ng enough social forces / slowness to impair spam.<br clear=3D"none"><br cl= ear=3D"none">> On Tuesday, November 12, 2013 1:07 AM, Michael Pearce<br = clear=3D"none">> <<a shape=3D"rect" ymailto=3D"mailto:michaelgpearce@= yahoo.com" href=3D"mailto:michaelgpearce-/[email protected]">michaelgpearce-/[email protected]= m</a>> wrote:<br clear=3D"none">> <br clear=3D"none">> Thanks for = the response! All good information. Its fun to think<br clear= =3D"none">> about how to build a system with the very specific constrain= ts that<br clear=3D"none">> Freenet imposes.<br clear=3D"none">> <br = clear=3D"none">> I'm not building a messaging application per se, but us= ers will need<br clear=3D"none">> to communicate and most identities wil= l not be very long-lived. This<br clear=3D"none">> is leading me t= owards thinking I can get away with a single key to<br clear=3D"none">> announce new messages.&nb= sp; I was also thinking about adding a Nonce to<br clear=3D"none">> the = message combined with an expensive hashing algorithm (i.e.<br clear=3D"none= ">> BCrypt) so spamming a user takes some work on the spammer's side.<br= clear=3D"none"><br clear=3D"none">May I ask what you're building? It will = be easier to give more informed<br clear=3D"none">and specific suggestions = with that knowledge.<br clear=3D"none"><br clear=3D"none">> A sender wou= ld create a message similar to:<br clear=3D"none">> <br clear=3D"none">&= gt; Sender <- my public identifier<br clear=3D"none">> <br clear=3D"n= one">> Recipient <- recipient's public identifer Nonce <- unique v= alue to<br clear=3D"none">> this recipient from the sender for this mess= age<br clear=3D"none">> <br clear=3D"none">> SenderSignature <- se= nder signs message with (recipient, nonce) to<br clear=3D"none">> ensure= sender is who he says he is AntiSpamHash <- Bcrypt(recipient,<br clear=3D"none">> nonce, mini= mum_rounds) to force some work on the sender<br clear=3D"none">> <br cle= ar=3D"none">> MessageBodyId <- location of signed/encrypted message b= ody located at<br clear=3D"none">> a different Freenet key<br clear=3D"n= one">> <br clear=3D"none">> As a receiver checking for incoming messa= ges, he only fetches the<br clear=3D"none">> message body for messages t= hat:<br clear=3D"none">> <br clear=3D"none">> * Have himself as the r= ecipient<br clear=3D"none">> * Have a unique Nonce from the sender (no d= uplicates to avoid<br clear=3D"none">> signature / anti-spam valu= e stealing)<br clear=3D"none">> * Correct signature at SenderSignature *= Correct AntiSpamHash<br clear=3D"none">> <br clear=3D"none">> If all= of these match, the receiver will then retrieve the message<br clear=3D"no= ne">> body.<br clear=3D"none">> <br clear=3D"none">> I think the a= bove scheme will allow for looking at the shared key<br clear=3D"none">> pretty quickly, and a com= putationally expensive AntiSpamHash will<br clear=3D"none">> disincentiv= ize large amounts of spam. Definitely not perfect but it<br clear=3D"= none">> may be good enough for my needs.<br clear=3D"none"><br clear=3D"= none">This is between individual users? This sounds a lot like Freemail's u= se<br clear=3D"none">case. Perhaps you could base your protocol on that, or= use Freemail as a<br clear=3D"none">transport? [0]<div class=3D"yqt0283351= 171" id=3D"yqtfd73220"><br clear=3D"none"><br clear=3D"none">Steve<br clear= =3D"none"><br clear=3D"none">[0] </div><a shape=3D"rect" href=3D"https://gi= thub.com/Thynix/Freemail/blob/spec/docs/spec/spec.tex" target=3D"_blank">ht= tps://github.com/Thynix/Freemail/blob/spec/docs/spec/spec.tex</a><div class= =3D"yqt0283351171" id=3D"yqtfd05443"><br clear=3D"none"></div><br><div clas= s=3D"yqt0283351171" id=3D"yqtfd67330">_____________________________________= __________<br clear=3D"none">Tech mailing list<br clear=3D"none"><a shape=3D"rect" ymailto=3D"mailto:Tech@fr= eenetproject.org" href=3D"mailto:[email protected]">Tech@freenetproje= ct.org</a><br clear=3D"none"><a shape=3D"rect" href=3D"https://emu.freenetp= roject.org/cgi-bin/mailman/listinfo/tech" target=3D"_blank">https://emu.fre= enetproject.org/cgi-bin/mailman/listinfo/tech</a></div><br><br></div> </di= v> </div> </div> </div></body></html> --1018116533-856279044-1384760403=:58388-- --===============0845124784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Tech mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech --===============0845124784==--