RetroShare: For the Paranoid in You!

by Dietrich Schmitz
(Originally published: 6/7/2013)

[Edit: Some raised concern about sharing their F2F key via regular email.  To use a 'darknet' method, try either cryptocat.bin or cryptocat.org]

It's all starting to make sense now.  We've heard rumors that this National Security Agency was snooping around in our private affairs.

Turns out, it's been going on for longer than we think, like, since 1952?  That's the latest.

So much for the book 1984.  Should have been 1952.  Okay so what if George Orwell was off by about 32 years.  Still, it's amazing how he pegged the future with such eery accuracy.

Okay great so, now what do we do given that our every move is being examined like getting a colonoscopy?

You should now not worry what people think if you take extra precautions with your privacy, particularly on the Interwebs.  That's right.  Let them call you paranoid and then throw one of these stories in their face and say with confidence: YES, I AM PARANOID AND I AM FINE WITH THAT!

So seriously, is there anything that can be done on the Interwebs without having it owned and/or seen by someone these days?

Actually, I am glad you asked the question.  It just so happens there is.

An interesting piece of software has been in development going on several years now, called RetroShare.  Errrm okay, sooooo.

So let's check it out.

RetroShare

What is RetroShare?

RetroShare is the next generation sharing network, which provides:

• Reliable Identification and Authentication of your friends.
• Plus an Introduction Scheme which connects you to the friends of your friends, and facilitates network growth.
• Encrypted Communication, ensuring all shared information is known only to you and your peers.
• A Communication Platform which can potentially support services such as Secure Email, File Sharing, Streaming, Video or Voice over IP, Photos, Wall and Messaging
• A Decentralised Social Sharing Network designed **For the People** with no dependancies on any corporate system or central servers.

RetroShare is built on GnuPG and is a serverless encrypted peer-to-peer network, but with a slightly different twist, called 'Friend-to-Friend' or F2F for short.

You see, this is a 2048-bit RSA-encrypted SSL tunnel through which your activity travels but every node along the P2P network is on its own 'private' channel.  In other words, there may be thousands of users using RetroShare but you only see those 'Friends' with whom you explicitly take the step of sharing your private F2F key.

Setting up RetroShare is easy.  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.

The result?  Log into RetroShare and immediately you'll see your Friend on the private chat, and if you choose you can also share file folders with them and also emails.

Probably one of the most interesting aspects of RetroShare aside from being P2P is that email is a totally closed loop--just between you and strictly your Friends.  For an email to reach you, the sender must possess a copy of your F2F key and you must have their F2F key.

It completely eliminates spam.  And provided that you are only friending people with whom you are personally familiar, there's no loss of privacy whatsoever, in terms of your private activities.

Aside from eliminating spam, it's going to be really hard for any kind of eavesdropping on this system because of the SSL tunnel and 2048-bit length RSA encryption key cipher strength.  How hard?  Reheheheheheheheheheheheheheheheheheheheheheeeeeally hard.  Here is an example of how hard:

I fully expect to see comments stream in with assurances that this key is crackable.  No one has been able to substantiate such claims to me.  But please, bring it.

Feature Summary

• Serverless, completely decentralised
• Multiple simultaneous downloads / uploads
• Search Friends
• Messages
• Forums
• Channels
• Voice over IP
• Instant messaging
• Groupchat
• GnuPG Authentication
• OpenSSL Encryption
• adding downloads via website links
• Plugins support
• UPnP / NAT-PMP port forwarding support
• Graphical User Interface written with Qt4 toolkit
• System tray integration

So Folks, this is really is a nice implementation and I seriously recommend you try it.  Now that cat has been let out of the bag that 'big brother' truly IS watching (like we didn't know pfffft chaahhh), go get your copy of RetroShare and let your paranoid Friends know about it too.

We can all live in a state of paranoia together, you know, as the paranoid circle of Friends on RetroShare. ;)

Be Safe.

-- Dietrich

Related articles

• Fighting CISPA with Encryption
• OpenPGP smartcards and Gentoo - part 2: card and gnupg setup
• NSA Can Wiretap Skype, Google & Facebook - But Not WebRTC
• Open source software vs. the NSA
• Is Paranoid Becoming Normal?

Read More

Is OpenSSL's Cryptography Broken?

by Dietrich Schmitz

Last month, in early August, a colleague Friend of mine, +Scott Doty contacted me.  He expressed his concern regarding Red Hat's implementation of OpenSSL.

The issue brought to my attention by Scott concerns a specific bugzilla ticket which was opened in 2007 and has never been addressed.

I offered Scott to reach out to Red Hat's public relations the same day he contacted me.  The answer returned the following day was essentially a 'no comment' and that I should refer to the comments section on the ticket -- deemed to be 'self-explanatory'.  If you take the time to review the ticket, you'll see where Scott appended his own comments in the August time frame toward the bottom.  It's fairly long.

Red Hat had absolutely no intention of fixing the bug, specifically, regarding the treatment of the Elliptic Curve Cryptography implementation in OpenSSL, and according to the comments on the ticket they felt ECC was patent encumbered.

Yet, in other sources on the Internet, one can find reference to a 'work-around' which would avoid any IP infringement issues.  Quoting from Wikipedia.org's ECC page:

"...However, according to RSA Laboratories, "in all of these cases, it is the implementation technique that is patented, not the prime or representation, and there are alternative, compatible implementation techniques that are not covered by the patents."[3] Additionally,Daniel J. Bernstein has stated that he is "not aware of" patents that cover the Curve25519 elliptic curve Diffie–Hellman algorithm or its implementation.[4] RFC 6090, published in February 2011, documents ECC techniques, some of which were published so long ago that even if they were patented any such patents for these previously published techniques would now be expired...."

Alright, so it struck Scott as being odd that such a bug was laying around collecting dust, and I agreed.

In the meantime, we have seen a series of news releases with Snowden giving out new information.  One of the claims has been that the capability of NSA to penetrate presumed to be secure cryptography standards has become much improved to such an extent that they are now collecting information flowing over SSL with impunity and have broken a few other cryptographic standards, purportedly.  I say this only because it's Snowden's word vs. the NSA and the NSA is completely 'mum' on the topic.

The sensational news story "Report: NSA Can Break Internet Encryption"arrived last week and created quite a stir.  The title is a carefully crafted wording.  Naturally, it is quite an unsettling thought to have all presumed Internet security breached, but the story's author hedged a bit at the end of his story saying:

"...Despite the NSA's ability to crack web encryption with these means, Wired's Kim Zetter notes that "these methods don’t involve cracking the algorithms and the math underlying the encryption, but rather rely upon circumventing and otherwise undermining encryption." 

And Snowden himself said during a Q&A with The Guardian in June that cryptography works. 

"Properly implemented strong crypto systems are one of the few things that you can rely on," he said...."

Now, the distinction to be made ties into the title of the story -- namely that, provided that an 'implementation' of strong cryptography coded 'properly' with no side-effect bugs cannot be hacked.

Put another way, bug-laden cryptography can result in weakening of the underlying cipher's strength and so can potentially be cracked.

This would seem to suggest that the NSA have found defects in various cryptographic standards, or, by whatever means, have introduced themselves intentionally crafted bugs in such a way to induce such weakening, thereby achieving their end-goal to crack encryption methodologies.

This led me to think more about OpenSSL and that languishing buzilla ticket.  Just yesterday, I had an exchange with +Jan Wildeboer to whom I regularly communicate, usually on Google Plus.  I broached the matter of the Red Hat OpenSSL bugzilla ECC ticket with him and curiously enough, today, he cc'd me with this Google Plus post (thank you Jan):

Mike Hearn

Shared publicly  -  10:29 AM

A few days ago Bruce Schneier, who has reviewed the leaked Snowden documents, warned against the use of elliptic curve cryptography on the grounds that it requires users to agree on curve parameters and he no longer trusts the parameters to not have back doors. Specifically he's talking about the NIST curves. NIST is a US organisation that was previously widely respected and considered trustworthy.

However, his warning seemed to be based more on general conservatism than any specific intelligence cleaned from the leaked documents. We know the NSA has tried to subvert the standards setting process and we know they may have advanced mathematical attacks that the public doesn't know about. ECC requires various constants to be agreed on globally for an instantiation to be used. Hence, the concern.

But that isn't specific evidence. Unfortunately, today I  learned (via Gregory Maxwell) that the process for selecting the "random" curve parameters appears on the surface to be completely implausible. The parameters are the output of SHA1, which should be good if the seed was selected in a reproducible manner. But they were not. The seeds are extremely large constants with no explanations of where they came from. That smells very strongly of something that might be hacked.

It gets better. It turns out that these constants are not only unexplainable but were actually generated by an employee of the NSA. And it turns out that the IEEE working group that worked on standards for ECC was actually holding its meetings on the NSA campus and its membership therefore had to be approved by the NSA as well.

At this point it is fair to assume that the NIST SECG curves should be abandoned for all uses. Bitcoin uses secp256k1 which was not selected in the same way and is more likely to be OK, and besides the NSA is unlikely to care about stealing peoples wallets (we don't use ECC for secrecy, just authenticity). And luckily academics like djb and Tanja Lange have created new variants of ECC independently of the NSA which are technically better anyway. But the upgrade process away from the SEC curves is going to be a pain.

So, that's quite interesting.  It would now appear that ECC is borked and quite possibly has been so for quite some time, thanks to the handy-work of the NSA.

The cat is now out of the bag.  I am now wondering how many other cryptographic standards need a thorough audit and scrubbing of any questionable code and fixing of languishing bugs?

-- Dietrich

Related articles

• On the NSA
• NSA's (and GCHQ) Decryption Capabilities: Truth and Lies
• Google confirms Java and OpenSSL crypto PRNG on Android are broken.
• Good SSL for your website is absurdly difficult in practice

Read More

RetroShare: True Internet Privacy Requires a Change of Habits.

by Dietrich Schmitz

I've been thinking about making changes to how I currently use the Internet.

One thing is for sure, it's hard to break old habits.

Of course, it's convenient to use Gmail.  And that it is unencrypted along with everything else including Drive is beside the point.

This convenience must be dealt with.  If your privacy is going to be protected, Americans, your only recourse is to employ encryption--unbreakable encryption.

And, I've been looking at RetroShare.

I think that RetroShare is perhaps the best example of what privacy-enabled software should offer.

But making a commitment to force oneself to adopt the needed technology is key.  It's not that hard to put into play.  I have RetroShare on my Netbook.  Let's see what it took to set it up.

Environment

First, I will say this is a discussion regarding the use of your 'home' PC.  I use PC to generically refer to your computing device.  It's an old term, and, I'm getting old.  Had an IBM PC in '83.  But I digress.  So, okay.  You are home and wondering how you can boost your privacy?.  Let's take a look at your Wireless Router.  Mine is a Cisco Linksys E3000, which I reflashed with DD-WRT, but yours may be any kind which supports uPnP.

Let's have a look at the router.  Bring up yours (my ip is 192.168.1.1) and login with your admin login id and password:

Enable uPnP support on your Wireless Router

The location of this information will vary according to your manufacturer's design.  Straight away, I am strongly recommending you use uPnP.  Why?  Because it will automatically make all of the port forwarding decisions for you.  Otherwise, you do have the choice to manually select an inbound TCP and UDP port and define the forwarding ip address of your PC on your home LAN.  But, I won't show how.  Just use uPnP if you have it.  Most routers support it.

RetroShare Software Installation

Okay with that out of the way, I am now taking you to the RetroShare website's download page.  On my PC, I am running Netrunner 13.06 Enigma, an Ubuntu derivative with KDE Plasma Workspace.  I'll just call it KDE.  I hope +Aaron Seigo and +Martin Gräßlin won't mind.  Anyhow, that means I can follow the directions pertaining to Ubuntu:

RetroShare installation instructions for Ubuntu

Sweet.  This should be easy.  And, it was.  I won't show you how to do the install steps.

So, great.  We've got RetroShare installed, you've input your name, email address, and created the needed GnuPG key and should arrive at this screen:

RetroShare main screen

There it is.  The main screen of RetroShare.  On the bottom of the window, note NAT and DHT.  If you are using uPnP on your router, both will be initially red and NAT will turn yellow and eventually green.  Both will become green all on their own without any further action on your part.  This is why I suggest uPnP.  It's the most painless way to get up and running.

If, however, your router doesn't support uPnP, you'll need to do some extra legwork on both the router side and on RetroShare in settings.  Let's take a brief look at settings:

RetroShare>Options (Gear)>Server screen

Click the gear on the left of your RetroShare, then Server and you'll see the above.  If you need to manually configure port forwarding on your router, you'll need to switch your settings to "Manually port forwarded" here.  This is the hardest part of setup on RetroShare.  But we are striving for maximal privacy here, are we not?  Yes.  I hope you will prevail and conquer this.  Be proud you did it.

And so we have presumably done the router configuration, installed RetroShare and can see we are on-line by the number of users across the peer-to-peer server-less system.

Connecting With Your Friends

Fantastic if you've gotten this far.  But, we are not doing much until we establish one or more Friends connections with people we know.  That sentence is subtle but the distinction here is important.

This isn't like a Bittorrent or Tor P2P system.  No, it is quite different and very restrictive.  It is a 'Friend-to-Friend' (F2F) 2048-bit RSA encrypted key system tunneled over Secure Sockets Layer (SSL) where all data moving along the Distributed Hash Table node list is multi-plex encrypted.

What that means is that all of the data is gibberish to anyone other than you and your designated 'Friends' with whom you have explicitly taken the crucial step to share your F2F public key.

Isn't that what you really want?  Yes, it is.  And one of the many benefits you will find in using RetroShare is that the exclusivity of F2F means that nothing will be on your private channel but what you choose, including email.  Yes, email will only go to and come from your Friends.  That means, NO SPAM.  Guaranteed.  Assured.  Isn't that great?

Alright, so sharing your public F2F key is something which you will want to exercise care doing.

Technically, you can go straight into email and send from RetroShare a Friend request to one of your gmail Friends.  But, if you take the 'ultra-paranoid' point of view (cough NSA PRISM), that email can be read by any third-party concern.  And, a rogue 'imposter' could conceivably assume the identity of one your supposed dear Friends.  That wouldn't be good.

What to do?  I think the simplest way to share privately your F2F key is to coordinate with them 'by phone call' a session for sharing, using either cryptocat.org or cryptobin.org.

It just so happens that I've tested both and they work quite well and are relatively easy to use and will become 'routine' after using once or twice.

The first thing you need to do is get a copy of your F2F key.  Where is it?  It is in Options>Profile>Certificate.  Don't be intimidated by what you see.  It's how encryption works.  You need to copy the certificate to the clipboard with the copy to clipboard button, or, right-click, select All, then right-click, copy to accomplish same.

There.  You've got a copy of the key.  Our goal here is to contact your Friend, have them do all of the preceding steps so they have RetroShare installed and ready to exchange F2F keys.  Here's the screen for the certificate:

RetroShare F2F Certificate screen

You'll notice, I intentionally erased a bit of the image to defeat anyone from copying my current F2F key.

Off we go with our Friend to cryptobin.org.  You'll see below, I have pasted in my F2F key, set the time to expire to 1 day and generated a password using the 'Generate' button.  If you leave the screen without recording the password, then your Friend won't be able to unlock the screen.  Ideally, if you have them on the phone, manually create a mutual strong password (no need to press Generate in that case).

If the user is not currently available, bookmark the url created by cryptobin and email it to your Friend.  Have them call you for the password.

Cryptobin.org screen where you can share your F2F key with your Friend securely.

And, they will do the same with you to exchange their F2F key.  Don't forget to press the 'Bin It!' button, which will encrypt your message and create the needed url for your Friend to access when they have time.

So where does the F2F key get added?  Click Add a new Friend, then select 'Enter the certificate manually' and press Next:

RetroShare Add a new Friend screen.  Select 'manual' and press Next

Now, you need to take the Friend's certificate which they sent to you using cryptobin and paste it into the second empty window and press Next:

Paste your Friend's certificate in second window

This is the Make Friend screen.  If I shared my F2F key with you, you'd be seeing my name as shown.  Only sign F2F keys for people you know personally.  This is important as GnuPG is based on the Web of Trust principle.  Here's a screenshot:

RetroShare Make a Friend screen

As you know this Friend personally, you should sign the key.  Click Finish and you are done!

Congratulations!  You are now connected to your Friend(s).

Now the fun begins with total privacy assured for Chat, email, file sharing, voice and video calling, Chat forums, and Channels.

As always, act responsibly, be a good Netizen, and obey all laws for your respective country.

I hope you will make a commitment and change your habits to reclaim your privacy.

Best of Luck and Be Safe.

-- Dietrich

Related articles

• RetroShare: For the Paranoid in You!
• Retroshare: A next generation secure communication and file sharing platform
• Maintaining Online Privacy and Preventing Identity Theft with New...
• Security & Privacy: Exploring the possibilities of secure decentralized instant messaging.

Read More