-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 12/08/2012 06:03 PM, Matthew Toseland wrote:
> On Wednesday 05 Dec 2012 06:55:13 Robert Hailey wrote:
>> 
>> On 2012/12/04 (Dec), at 8:10 PM, Arne Babenhauserheide wrote:
>> 
>>> Am Donnerstag, 1. November 2012, 21:30:35 schrieb Matthew 
>>> Toseland:
>>>> - More work on making darknet easy.
>>> 
>>> Yes, please!
>>> 
>>> How about automatic insert of my noderef as CHK, so I can just 
>>> hand a friend an in-freenet-link to connect?
>> 
>> So you want a sort of... "open invitation"? Whoever finds the chk
>> can become a darknet peer... unless the operator has put a 
>> count-limitation on it, or since disabled it manually (via an 
>> open invitations list?).
>> 
>> An interesting idea, and not a bad one either, as it would be a 
>> necessary first step for the welcome-package idea anyway as the 
>> "one_time_token.txt" is effectively a limit-1 open-invitation.
> 
> Invites should be one-time yes.
>> 
>> It seems like it would remove 50% of the handshake process for 
>> those who find it "secure enough" for their purposes, but I think
>> Matthew said something about it not gelling well with 
>> darknet-only nodes being "undetectable" (that they would have to 
>> respond to an unverified request or something).
> 
> That's why invites should be one-time. Making them both one-time 
> and very short might be problematic, but is impractical anyway in
> a lot of cases.
> 
> Maybe an easily scanned visual representation? What were those 2d 
> barcode like things called? They have very few bits but we could 
> improve on that with e.g. using primary colors...

Looks like a version 10 QR code can have anywhere from 119 to 271
bytes, depending on the level of error correction. [0][1] At the low
end that's enough for the linkageddon key, for instance, but just barely.

My impulse is to shy away from rolling our own offshoot of QR codes,
though. That would negate the benefit of using something already
established.

>> 
>> Relatedly, it seems to me that the most likely onboarding 
>> use-case is simply two persons that want to have a secure 
>> conversation between themselves (maybe not even as a darknet 
>> peer, as it would cause a direct IP link between them). 
>> Therefore, I would see the common use-case being the easy 
>> fabrication of an (incredibly specialized) linux boot-usb-stick, 
>> that is used when needed to send/receive queued messages.
>> 
>> I'm not sure if it would be easier or harder than a zip-invite, 
>> as you'd only have to maintain one OS 'installer' to maintain, 
>> but it'd be more all-inclusive and prone to feature-creep (like 
>> encrypting the entire usb stick). Then again, if the image was 
>> pre-built (e.g. by authoritative freenet servers, or anonymous 
>> freeneteers with a special interest in such), then all the client
>> app would have to do is inject the invitation (by offset or
>> overwriting magic content), and probably recompute a CRC (or is
>> that only for cd/dvd images...).
>> 
>> Either way, the open-invitations you mentioned would be needed 
>> first.
> 
> Implementation: Darknet peer flagged as LISTEN ONLY, where the 
> noderef deliberately does not include any means to contact it. The 
> receiver should ideally not record the IP address it last connected
> from either. Receiver must be port forwarded. IMHO anything where
> one side absolutely must be port forwarded is impractical, a lot of
> people aren't, granted a lot of the time not being port forwarded
> means Freenet doesn't work at all but it's not true *all* the
> time...
> 
> A related use case, "upload on the run" works even on opennet 
> provided you are expendable, or expect to be elsewhere very soon 
> afterwards, and can 1) bootstrap fast enough, 2) upload fast 
> enough, 3) announce your uploaded content fast enough and 4) 
> confirm that it's announced fast enough. #3 and #4 are problematic 
> at the moment, but I have solutions for them. Obviously if the bad 
> guys control the seednodes - or all the seednodes you can connect 
> to - then you lose.

[0] https://en.wikipedia.org/wiki/Qr_code#Storage
[1] http://archive.is/20120915/http://www.qrcode.com/en/vertable1.html

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJQw9W9AAoJECLJP19KqmFuT0cQAJ2jBC3X7mrjgnbgaqiYKY+U
ZBNtYpdJtGI8geHg0HsdCGOWXIaigEofBbTXzXlOKXMFyy+7DF0p79W9KV2cDa8w
pHh2NoFFRB/00ocvT6zGa1B3je75TR/4MEBCEFtAbwYsQbdDUc5e/nuJGoxbjtVT
+ddjyo6mVAATCSRj45RYApDdv7P8H2S55Y2AErbzgckROXNjFDKyhdPNR+ta4jQ7
PD2TVViolgEa+MhoVE3pgUVCapWxtbNUo4GpdiVFImct89i1uaXklcKC85Y685tB
y8zDwq6lBSTFbFLFADIwbeARz/yFQeum8uYqrfcIb5GK7iADjQqc4oDtLQkN1G8q
Z7wzQuskxGyVgPgQj4yxYk/1LrIeSboQ2iqMZrNdJeqamIjLQMYxfHPtpGi/fMkd
ny7fZ9Z6Sz4MMgQ+VmdzFtJp2pFZq0QKICwuKaUnlzjd58Dzmvq8PiDBh2O2yytM
PB1pxIQs1LhIr0Rtx3hIhKba+u2jCZVCISM/dlRyETUStif1+2fzFqHEvY1KXSET
LPVbCuwPg0RfNhOpegYrTY5bIEMVMRfweFzHgvUQXxnYPxAH7BtiuCyd9x0plrAj
r1J9RgZEv/LUzcyk/hAO46luqQGt19eXdO35bE5y0HwZS6DuJEoZAuDot8NZ36+N
tIZhUyYj2Z40L0At8+eB
=vECe
-----END PGP SIGNATURE-----
_______________________________________________
Devl mailing list
Devl@freenetproject.org
https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to