RetroShare: For the Paranoid in You | Hacker News Reader

RetroShare: For the Paranoid in You

linuxadvocates.com

89 pointsbuovjaga40 comments

I'm no security expert, but at least in theory Retroshare may be one of the safest ways to communicate out there (along with some of the OTR-enabled apps; Retroshare doesn't use OTR, I believe, just P2P OpenSSL).

When the general Petraeus scandal happened, I was thinking that if he would've used Retroshare, which is P2P and encrypted, to talk to his mistress directly, he wouldn't have been found out (unless his PC had a keylogger).

Now if only someone made a prettier interface for it, so "normal" users would be compelled to use it.

EDIT: More info on its security and privacy models, by the team behind it:

Ideals:

http://retroshareteam.wordpress.com/2012/11/03/retroshares-a...;

On security:

http://retroshareteam.wordpress.com/2012/12/28/cryptography-...;

On privacy:

http://retroshareteam.wordpress.com/2013/01/06/privacy-on-th...;

Distributed chat:

http://retroshareteam.wordpress.com/2012/11/16/distributed-c...;

Agreed. The main sticking point for Retroshare is it's atrocious interface. I love the concept but can't bring myself to actually use it.

This really was/is the main sticking point around free software. The UX is awful until a designer comes along and fixes it.

Or ruin it...

Contributing any sort of design to an open source project is often a horrible experience.

Probably explains why it rarely happens.

It's open source. You don't even have to talk to the developers if you'd rather not. Fork it and make it beautiful, and release it. The world will thank you. If there's enough demand, the devs will merge it into the original project.

If I was a designer and not a programming type, this would be extraordinarily difficult, especially when it comes to refactoring someone else's code and interface to fit my vision.

Indeed design is not about sticking a pretty UI on top of the existing software.

You have to apply UX to the development process, such as how a user interacts with features, or the steps involved in each action, or the way the app communicates to the user, or delivering feedback after an interaction is completed. Design influences the software requirements.

It's necessary for designers to collaborate with developers if you want a well designed app... not just a pretty one.

The Retroshare no-gui version is almost feature-complete. The no-gui version will allow all kinds of interfaces as can be imagined. The Android version is still under active development: https://github.com/G10h4ck/RetroShare-Android-Client

What happens if one one assumes that the likes of the NSA can directly access one's computer and poke around at will?

For years Microsoft has been accused of building or allowing back doors in to windows. If that is true, none of these schemes will work, right?

For years now, I have just assumed that my computer is a government spy sitting on my desk. OK, paranoid, no real proof what so ever, and OTT. But, I feel it is wise to assume and act like that is true. Or, know the risk you are taking.

How to be secure on the internet? Don't use the internet.

Use linux?

See my comment here: https://news.ycombinator.com/item?id=5837776

What if the CIA infiltrated Intel. So the i3 - is a dual core with the 3rd core that belongs to the US, similar to i5 and i7. :-)

Why would you possibly need to add an extra core to the CPU to spy on people? What you're thinking of is more like LOM, where there's a second, low-power processor to remotely control the whole computer even in a powered down state. Depending on the level of integration that might give you cross-platform snooping, but it wouldn't be Intel and Microsoft, it would be Asus, Asrock, Gigabyte, MSI, etc.

The extra cpu runs its own operating system. It has hooks into the main cpus - can read their registers on every clock cycle and an in built radio transmitter. when many of them are put together they form their own cluster, something on those lines.

You mean the Management Engine (mandantory to supply with Intel-proprietary firmware since 5 series)? Since it's the key components of Intel AMT, its features are - at a minimum:

- can run while the CPU is off

- isn't controlled by the CPU (except some protocol which is voluntary on the ME side)

- has access to the onboard GPU's framebuffer

- has access to onboard USB and on-chipset NIC

- can access RAM, bypassing the OS (_maybe_ host-controlled, since the only known use is IDE-R)

Scary enough?

On AMD the situation looks safer for now: while they have _two_ embedded controllers with firmware, from what we (coreboot developers) could gather, their reach into the system is much more limited: they could probably DoS the system by killing access to RAM and/or turn off the fans

If I was the CIA/NSA I would definitely force Intel/AMDs hand to put a kill switch on the chip. That way if I was waging war with country, I first broadcast a special signal killing off all the CPUs I can. Then we launch our attack.

The kill switch could be anything:

1. Some particular frequency that causes the CPU to malfunction deliberately. Just a 1 bit malfunction is enough. 2. Something delivered via an OS update patch.

Only a matter of time before a nefarious person discovers how to trigger the kill switch at their will. If this happens, Intel will immediately go out of business. They know they can't just blame the NSA. That's why Intel has every incentive to aggressively fight such orders.

Yep, it's amazing how many people start by assuming that their OS is safe... and there's no basis for this assumption, even without assuming intentional backdoors baked in, there are some many 0 day exploits for all the software we use daily that...

...heck, I'm not even 90% sure that compilers don't add backdoors to software (it's not paranoia... but with a 30 y o idea, you can imagine that people have had time to refine it to unimaginable subtlety :) http://cm.bell-labs.com/who/ken/trust.html)

The only alternative to making this assumption is to treat computers as compromised non-trustable entities, forgoing their use as true extensions of the mind and leaving all individuals at the mercy of the ever-growing computing system. Instead, we treat the assumption as fact, making do with the imperfect OSs we have and incrementally fortifying them to solidify the assumption.

maybe some prisoners of Guantanamo could be proofs of this

One important thing with RetroShare: Don't add random strangers that you don't trust.

Once you have someone as your "friend", random traffic will go between you and him (the network works as sort of p2p). If that "friend" is actually some government agent/copyright enforcer, you can then have troubles with illegal sharing of files, even when you didn't share them yourself.

This is not theoretical, this actually happened in... Germany or France, I am not sure. Probably France.

About the case in Germany: http://retroshare.sourceforge.net/forum/viewtopic.php?f=3&t=...

Quote from the post: the IP's of the sued user "rechner3" was from an IP Range from the lawyers (Rasch Legal).

The e-mail of the user "rechner3" was "pm.hh.04@gmail" it is possible that pm stands for the anti Piracy Company "ProMedia" hh == "Hansestadt Hamburg".

and other indications that lead to the lawyer company and anti-piracy company.

The maximum value of discussion was 10k. If a lawsuit had been started, this value would have been cut down. There was never a lawsuit to discuss the case and start a prove collection or discussion.

There is only a contract with rechner3 and the anti-piracy company, where rechner3 committed to not use RetroShare again.

rechner3 was never seen afterwards.

It looks like, this was a "forged" case to be present in the media with a high value sentence.

Thanks for this information, I didn't knew that and I admit, I took the original report at a face value.

However, the general point still stands - RetroShare is routing random traffic through you, if you happen to be near the nodes.

Isn't the data encrypted? How can even another friend see what's within the encrypted data?

This makes it another reason to use Bitmessage instead.

Does it imply that any random (p2p and/or encrypted) traffic between two hosts or users makes them suspicious of illegal file sharing activities ?

What about protocols and implementations such as bitmessage then (p2p network, hosts and nodes share everyone's messages, only intended recipients can decipher messages that are sent to them)? Is there a tacit understanding that encrypting any communication is suspicious ?

> Once installed, you send an email to your Friend(s) with a copy of the F2F key. Then, they do the same, by installing RetroShare and sending you their F2F key.

Uhm.

Yeah, key exchange is always hard. You need to use a secure channel for that, we found a OTR-encrypted jabber-message the easiest way to go.

Sadly, RetroShare didn't really work for us. The UI is too clunky and the software has too many weird issues, like reindexing all files occasionally.

Then you need to secure the OTR channel, i.e. authenticate the remote users; the same goes for using PGP-encrypted email – in both cases, it is almost impossible to securely authenticate someone who isn’t sitting next to you.

Yes, you should do this. Mechanisms for authentication of OTR-chats is build into the usual plugins (exchanging a secret). It is not almost impossible - in doubt, just call him.

Exactly. One phone call to verify the signature is all you need. Skype (or any other insecure (against passive attacks, i.e. the attacker shouldn't be able to modify what's going between you) channel) will work just fine, as long as you can be sure you're talking with the person you think you're talking to.

Yes, if you compare fingerprints, then the important point is to authenticate both sender and content of the message. ‘Common Secret’ authentication as it is supported by OTR with Skype as the channel to negotiate that secret won’t be any good, nor will Skype text chat be sufficient to authenticate the sender of the message.

If it absolutely has to be remote, I’d go for a combined audio/videocall on Skype where one reads out the fingerprint and holds up a (ideally hand-written) sign with it – though I’d still prefer IRL-authentication (plus it’s more fun! :)), and ‘only authenticate keys in real life’ looks like a helpful rule-of-thumb to me.

Why is just reading the fingerprints to each other via video chat insufficient?

for those who just would like an encrypted chat. i‘m very happy with the otr plugin for pidgin. additionally every adium (macos) user could use this feature ootb. but.. maybe the hardest part.. you have to convince your "i dont care"-"i have no secrets" colleagues to use it.. :)

If only it would run on the browser. Installing something is a big barrier this days.

With WebRTC this might actually work. But there's still an issue with trusting code that is redownloaded from the net all the time. (The WebApp things from Chrome and Firefox might come to help here, once they support both signed code and version pinning)

check AES.io

why is it a barrier? there's already significant local setup implied in establishing trusted keys.

If I understand it right, it doesn't offer deniability.

If you want a system with encryption and deniability, try Bitmessage.

https://bitmessage.org

This is fantastic. I've been wanting to create something like this for a few years now but never actually did anything about it. Now I have an existing project to contribute to.

Nice :) Please do.

If you're paranoid, use QubesOS and run Retroshare and other things in isolated VMs. I loved Retroshare except for the part of never being able to delete stuff you posted.

Reply on news.ycombinator.com