I'm not 100% sure how this might work, but having opennet require a security device might be publicly acceptable, and might also serve as the monetary disincentive to an opennet sybil attack.
Without looking too much into it, I supporting a smartcard interface from java (across many platforms) would be problematic. A one-time-password (OTP) solution might work, though. One such device I have experience with: http://www.yubico.com/products/yubikey-hardware/yubikey/ Such an onboarding user story might look like this: (1) a new user browses the freenet site and finds out that freenet generally requires a yubikey (2) they install freenet, but it doesn't work (or works poorly), and also says something about needing a yubikey (3) we lose a bunch of lookie-loos with an interest in freenet that is <$15+time, but security-interested folks might be further interested in getting "the security device that freenet requires" anyway (4) so those that remain order a yubikey (min quantity 1), (5) a few days later, the device arrives (quick-ish, as singletons are mailed in an envelope) (6) they go back to freenet, click in the "yubikey field" and mash the "button" (it's actually a capacitance sensor, I think) (7) through some mechanism not visible to the user, the OTP is verified and an opennet certificate is issued Maybe at some semi-obvious state change (like a machine reboot, or the yubikey being used on another N machines?) or period (monthly), the field would popup again to make it seem important & remind the user that a yubikey is needed to spread freenet. The generated OTP has a prefix that uniquely identifies it (sorta like a serial number), and can only be verified *once* (it is then, by definition, stale). If we use the default "short-press" identity that comes with the key, then we would be implicitly trusting YubiCo to not hand out gobs of identities to an attacker (i.e. without paying). In fact, that's the only option really... we could not use a custom identity, b/c either we would have to supply/program the keys or we'd be right back to a sybil attack (they just put the OTP algo in software). The implementation of step #7 really depends on wether or not we trust our seed nodes, and wether or not making a conventional http/https connection is acceptable. NB: we could always bundle a public key in with freenet to make it "safe" to hand off an encrypted OTP for delivery back to the mothership... I mean, "central server". -- Robert Hailey On 2013/07/21 (Jul), at 1:55 PM, Matthew Toseland wrote: > Would you pay to join opennet? Bear in mind that a paid system could have an > interesting level of security - not quite up to that of a real darknet, but > most attacks would be *far* more expensive. > > When I say pay, I mean pay once, to create a node. You can then stay on > opennet for as long as you like. > > And there'd be a fallback: Transient mode. Less anonymity, but it could still > use tunnels. Significantly less performance. What paying to join opennet gets > you (along with having some specified amount of bandwidth per peer), is the > ability to be part of the *backbone*, i.e. the storage network. Hopefully the > network would be somewhat faster because of the bandwidth requirements. And > it would have proper tunnels. > > Straw poll, but thoughts welcome. Some of the technical details spelled out > on the 1.0 proposal (http://piratepad.net/TQYpA3SDu7 ). No idea re legal > issues. > > Existing users would likely be grandfathered in, for a limited period and > subject to the same bandwidth requirements (and IP address requirements). > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
