[Forwarded from FMS] 0.8.0, the two big security issues
3BUIb3S50i <[email protected]> Mon, 12 Jul 2010 21:09:12 +0000
| Newsgroups | gmane.network.freenet.general |
|---|---|
| Message-ID | <[email protected]> |
--===============1678009975== Content-Type: multipart/alternative; boundary=00032555ac1a1a796c048b372a04 --00032555ac1a1a796c048b372a04 Content-Type: text/plain; charset=UTF-8 oo@lkXpu0~CDV6dh0Idyw4MBwkUSgn~h~Bs3qqVXYOXSaY wrote : > The Seeker wrote: > >> On 7/11/2010 6:21 AM, oo@lkXpu0~CDV6dh0Idyw4MBwkUSgn~h~Bs3qqVXYOXSaY wrote: >>> johnie@6kzjmQCFtZFFEJ0WThb29r63T5JkJg2Xy5hZSvItG1A wrote: >>> >>>> Matthew Toseland<toad-EI5O+8PHWbJeeLb3ft/[email protected]> >>>> >>>> IMHO we should attempt to fix, or at least realistically work around, the two >>>> big known security issues for 0.8.0, and get a paper published at the same time >>>> as the release. These are: >>>> 1. The Pitch Black attack. Oskar has a good idea how to fix it but has not yet >>>> simulated a fix. This blocks publishing a paper, and it also prevents use of >>>> darknet anywhere where there may be internal attackers. As I understand it >>>> implementation should not be particularly difficult - the main work needed here >>>> is to implement it in a simple simulator and tweak it until it works, right? >>>> 2. The mobile attacker source tracing attack. What this means is an attacker >>>> knows what is to be inserted (or requested), and he is initially distant from >>>> the inserter. He recognises the blocks, and uses the keys' locations (and path >>>> folding, and possibly announcement) to move towards the originator, gaining more >>>> and more of the stream as he moves closer. This is primarily a problem on >>>> opennet, but it is also feasible on darknet - it's just massively more >>>> expensive. It can be worked around for inserts by: >>>> i) Inserting with a random splitfile key. THIS IS IMPLEMENTED AS OF 1255, >>>> provided you insert to SSK@, AND >>>> ii) Providing an easy to use selective reinsert mechanism, AND >>>> iii) Putting a timestamp on the inserts on any small reinsert, and only routing >>>> to nodes that were connected prior to that timestamp. >>>> IMHO the second and third items are relatively easy. >>>> >>>> At the same time, we can substantially improve data persistence (1255 already >>>> does that for big files, but the insert tweaks that are going to be tested real >>>> soon now would probably gain us a lot more), ship Freetalk, WoT and FlogHelper >>>> for improved end-user functionality, a fixed wininstaller, lots of bug fixes and >>>> minor usability tweaks, and everything else we've done since 0.7.5. >>>> >>>> And having a paper published at the same time would surely help with publicity >>>> amongst certain kinds of folk. >>> >>> *lol* >>> Is this the same Toad who managed to break all nodes since 1250+? >>> Must have been fun for latest users, he will have to publish a lot of >>> papers to attract more users than are currently leaving. >>> >>> New, promised features are worthless if the node is broken and resets your >>> datastore or up- and downloads. >>> >>> What is he smoking to call this *improved persistence*? >> >> Thanks for all your hard work testing pre-release builds, it's thanks to the >> input of people like you during testing that we get the quality of product that >> we do. > > If you tried being sarcastic you failed. > > We all are running pre-release builds, no matter what Toad calls them and > no matter whether he declares a build to be 0.80. > > Is there any developer reading and writing here? > Or maybe in Frost? > Can you explain to me why Frost was secure enough for Toad on 0.5 but not > on 0.7? > If he is panicked by the bots (which bots btw.), shouldn't it at least be > possible to announce a build in a keyed board if he still rejects to > communicate? > > Do you think adding hashes to metadata was an improvement? > > As expected the real bug hasn't been fixed, files still get corrupted when > being inserted, did I write already that this seems to be a bug in FEC data > (some downloaders are affected, some not, the older the file the lower the > chance to get it uncorrupted)? > > True, the downloading node now detects this corruption and throws away all > blocks, just saying hash mismatch. > With previous builds one was able to repair corrupted files, read about > Quickpar. > Now your node says "sorry, this file is toad, I can't pass it on to you". > > Great improvement, isn't it? > Can you please ask him to remove hash check as long as he doesn't fix the > real bug? > We know ourselves when a file is corrupted. > We don't need the node to detect it when downloading the file, we need a > node not corrupting the file when it is being inserted. > > I could continue my rant with p0's comment about NNTP not being of primary > interest for Freetalk, Webinterface to be sufficient. > > Over and out. --00032555ac1a1a796c048b372a04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable oo@lkXpu0~CDV6dh0Idyw4MBwkUSgn~h~Bs3qqVXYOXSaY wrote :<br>> The Seeker w= rote:<br>> <br>>> On 7/11/2010 6:21 AM, oo@lkXpu0~CDV6dh0Idyw4MBwk= USgn~h~Bs3qqVXYOXSaY wrote:<br>>>> johnie@6kzjmQCFtZFFEJ0WThb29r63= T5JkJg2Xy5hZSvItG1A wrote:<br> >>><br>>>>> Matthew Toseland<<a href=3D"mailto:toad= @amphibian.dyndns.org" target=3D"_blank">toad-EI5O+8PHWbJeeLb3ft/[email protected]</a>><= br>>>>><br>>>>> IMHO we should attempt to fix, or a= t least realistically work around, the two<br> >>>> big known security issues for 0.8.0, and get a paper publi= shed at the same time<br>>>>> as the release. These are:<br>>= ;>>> 1. The Pitch Black attack. Oskar has a good idea how to fix i= t but has not yet<br> >>>> simulated a fix. This blocks publishing a paper, and it al= so prevents use of<br>>>>> darknet anywhere where there may be = internal attackers. As I understand it<br>>>>> implementation s= hould not be particularly difficult - the main work needed here<br> >>>> is to implement it in a simple simulator and tweak it unti= l it works, right?<br>>>>> 2. The mobile attacker source tracin= g attack. What this means is an attacker<br>>>>> knows what is = to be inserted (or requested), and he is initially distant from<br> >>>> the inserter. He recognises the blocks, and uses the keys&= #39; locations (and path<br>>>>> folding, and possibly announce= ment) to move towards the originator, gaining more<br>>>>> and = more of the stream as he moves closer. This is primarily a problem on<br> >>>> opennet, but it is also feasible on darknet - it's jus= t massively more<br>>>>> expensive. It can be worked around for= inserts by:<br>>>>> i) Inserting with a random splitfile key. = THIS IS IMPLEMENTED AS OF 1255,<br> >>>> provided you insert to SSK@, AND<br>>>>> ii) P= roviding an easy to use selective reinsert mechanism, AND<br>>>>&g= t; iii) Putting a timestamp on the inserts on any small reinsert, and only = routing<br> >>>> to nodes that were connected prior to that timestamp.<br>&= gt;>>> IMHO the second and third items are relatively easy.<br>>= ;>>><br>>>>> At the same time, we can substantially im= prove data persistence (1255 already<br> >>>> does that for big files, but the insert tweaks that are go= ing to be tested real<br>>>>> soon now would probably gain us a= lot more), ship Freetalk, WoT and FlogHelper<br>>>>> for impro= ved end-user functionality, a fixed wininstaller, lots of bug fixes and<br> >>>> minor usability tweaks, and everything else we've done= since 0.7.5.<br>>>>><br>>>>> And having a paper pu= blished at the same time would surely help with publicity<br>>>>&g= t; amongst certain kinds of folk.<br> >>><br>>>> *lol*<br>>>> Is this the same Toad wh= o managed to break all nodes since 1250+?<br>>>> Must have been fu= n for latest users, he will have to publish a lot of<br>>>> papers= to attract more users than are currently leaving.<br> >>><br>>>> New, promised features are worthless if the no= de is broken and resets your<br>>>> datastore or up- and downloads= .<br>>>><br>>>> What is he smoking to call this *improved= persistence*?<br> >> <br>>> Thanks for all your hard work testing pre-release bui= lds, it's thanks to the<br>>> input of people like you during tes= ting that we get the quality of product that<br>>> we do.<br>> <br= > > If you tried being sarcastic you failed.<br>> <br>> We all are r= unning pre-release builds, no matter what Toad calls them and<br>> no ma= tter whether he declares a build to be 0.80.<br>> <br>> Is there any = developer reading and writing here?<br> > Or maybe in Frost?<br>> Can you explain to me why Frost was secure = enough for Toad on 0.5 but not<br>> on 0.7?<br>> If he is panicked by= the bots (which bots btw.), shouldn't it at least be<br>> possible = to announce a build in a keyed board if he still rejects to<br> > communicate?<br>> <br>> Do you think adding hashes to metadata w= as an improvement?<br>> <br>> As expected the real bug hasn't bee= n fixed, files still get corrupted when<br>> being inserted, did I write= already that this seems to be a bug in FEC data<br> > (some downloaders are affected, some not, the older the file the lower= the<br>> chance to get it uncorrupted)?<br>> <br>> True, the down= loading node now detects this corruption and throws away all<br>> blocks= , just saying hash mismatch.<br> > With previous builds one was able to repair corrupted files, read abou= t<br>> Quickpar.<br>> Now your node says "sorry, this file is to= ad, I can't pass it on to you".<br>> <br>> Great improvement= , isn't it?<br> > Can you please ask him to remove hash check as long as he doesn't = fix the<br>> real bug?<br>> We know ourselves when a file is corrupte= d.<br>> We don't need the node to detect it when downloading the fil= e, we need a<br> > node not corrupting the file when it is being inserted.<br>> <br>&g= t; I could continue my rant with p0's comment about NNTP not being of p= rimary<br>> interest for Freetalk, Webinterface to be sufficient.<br> > <br>> Over and out. <br><br> --00032555ac1a1a796c048b372a04-- --===============1678009975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ chat mailing list [email protected] Archived: http://news.gmane.org/gmane.network.freenet.general Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat Or mailto:[email protected]?subject=unsubscribe --===============1678009975==--