OHAI, So, this project has been noted here on several occasions, but I still lack some serious opinions. Here's a chance to voice them. What do you think of RetroShare? http://en.wikipedia.org/wiki/Retroshare http://retroshare.sourceforge.net/ inb4 "Java suxxorz" -- yes, I tend to hold that view myself; hoever, if RetroShare is a workable solution, we can simply add C++/Python/Whatever implementations later, right? -- Pozdr rysiek
On Sat, Nov 16, 2013 at 08:00:08PM +0100, rysiek wrote:
inb4 "Java suxxorz" -- yes, I tend to hold that view myself; hoever, if RetroShare is a workable solution, we can simply add C++/Python/Whatever implementations later, right?
Of course it is possible to add memory/type unsafe implementations later. Actually, RetroShare is developed in C++/QT.
Dnia sobota, 16 listopada 2013 20:47:21 Hannes Frederic Sowa pisze:
On Sat, Nov 16, 2013 at 08:00:08PM +0100, rysiek wrote:
inb4 "Java suxxorz" -- yes, I tend to hold that view myself; hoever, if RetroShare is a workable solution, we can simply add C++/Python/Whatever implementations later, right?
Of course it is possible to add memory/type unsafe implementations later.
What you did is there and I see it.
Actually, RetroShare is developed in C++/QT.
Oh, I got Retroshare mixed up with Sneer, then. That's great. -- Pozdr rysiek
I am presently using it. I have connected with a significant portion of the network. I find it is largely inert. The software is not without flaws. It's design is monolithic, causing any error to crash the entire system. Plugins increase the fatal error surface, attack surface and functionality. The greatest problem with plugins is that I'm never sure how they deal with my anonymity. I think Retroshare could well be replaced by something alike Tor, but not Tor, then to have some quantity of programs connect to it to do interesting things. That makes it more confusing that it exists, because Tor does already too. So, why use Retroshare instead of a Tor hidden service with standard chat relay? Because Tor is a target and RetroShare is not. And because Retroshare actually does a lot more than relay chat. I do not have a solid recommendation. I use it for curiosity reasons now. Although occasionally stimulating in it's novelty I find it unfit technically and practically for critical work. It still seems to be the best tool for the job, not unlike the rock-and-stick tools were the best for cutting lumber in days long past. 2013/11/16 rysiek <rysiek@hackerspace.pl>
inb4 "Java suxxorz" -- yes, I tend to hold that view myself; hoever, if RetroShare is a workable solution, we can simply add C++/Python/Whatever implementations later, right?
I think the implementation is messy. It might be less then normally convenient to add other implementations.
Dnia sobota, 16 listopada 2013 22:19:03 Lodewijk andré de la porte pisze:
I am presently using it. I have connected with a significant portion of the network. I find it is largely inert.
(...)
I do not have a solid recommendation. I use it for curiosity reasons now. Although occasionally stimulating in it's novelty I find it unfit technically and practically for critical work. It still seems to be the best tool for the job, not unlike the rock-and-stick tools were the best for cutting lumber in days long past.
Thank you for your comments. These are valuable, and they seem to confirm my (short) experience with it.
2013/11/16 rysiek <rysiek@hackerspace.pl>
inb4 "Java suxxorz" -- yes, I tend to hold that view myself; hoever, if RetroShare is a workable solution, we can simply add C++/Python/Whatever implementations later, right?
I think the implementation is messy. It might be less then normally convenient to add other implementations.
I am more interested in the protocol. People are already using RetroShare, right? It's FLOSS, it has some sort of a protocol underneath. So it is possible to create new implementations that do not make errors of the original one. *IF* (and that's a pretty big "if") the protocol is solid, of which I have no way to ascertain. So I guess this is my question: does RetroShare's protocol seem solid and sensible? Should we invest time and effort into it? As it is the first DHT-based communication and filesharing application/system based on strong encryption that is actually usable -- at least from what I have seen. -- Pozdr rysiek
2013/11/16 rysiek <rysiek@hackerspace.pl>
So I guess this is my question: does RetroShare's protocol seem solid and sensible? Should we invest time and effort into it?
It's basic concepts are pretty well considered. It's quite like Tor only the first nodes are "trusted nodes" and not just any random one. That said I think the whole RetroShare thingy is shot to hell regarding traffic analysis. That's hard for everyone except the Top Secret level people. Far as I know there's no deep-communication tactics except store-and-forward for forums. That's some weakness if you ask me. Finding a file based on a hash requires broadcasting the request for the hash, which will likely flood through (part of) the network. Tracing back a flood is pretty easy with a few nodes. Invest in it? Not a bad thing to invest in. But it's not that special on the crypto/security level AFAIK. I think the whole P2P thing is a bigger deal than the crypto part of it.
Dnia sobota, 16 listopada 2013 23:19:58 Lodewijk andré de la porte pisze:
2013/11/16 rysiek <rysiek@hackerspace.pl>
So I guess this is my question: does RetroShare's protocol seem solid and sensible? Should we invest time and effort into it?
It's basic concepts are pretty well considered. It's quite like Tor only the first nodes are "trusted nodes" and not just any random one. That said I think the whole RetroShare thingy is shot to hell regarding traffic analysis. That's hard for everyone except the Top Secret level people.
Far as I know there's no deep-communication tactics except store-and-forward for forums. That's some weakness if you ask me. Finding a file based on a hash requires broadcasting the request for the hash, which will likely flood through (part of) the network. Tracing back a flood is pretty easy with a few nodes.
Invest in it? Not a bad thing to invest in. But it's not that special on the crypto/security level AFAIK. I think the whole P2P thing is a bigger deal than the crypto part of it.
Or, more precisely, how it *combines* crypto and P2P. Plus usability: while it's not a staple of it, it is definitely easier to set-up and use than XMPP+OTR over TOR, while the effect is more or less the same -- you get an encrypted, trusted comms channel. Wonder however if RetroShare gives you plausible deniability? -- Pozdr rysiek
Retroshare isn't "like tor", it's "the opposite of tor". Tor establishes a network of mutual distrust (kinda; you still trust some aspects of the network such as the directory servers). Retroshare establishes a network of mutual trust, although you can withhold certain details such as whether you or merely a friend known to you is sharing the files you make available (although as mentioned by another this is likely to be traceable with enough network data). For high-security work, something like i2p or Tor is probably better. For an alternative to daily, casual internet traffic, Retroshare's *idea* is probably superior; by relying on existing relationships of trust, you can probably get better performance, and data that's relevant to your interests is likely to be nearby in the network because of social networking effects. However, the flipside is without existing relationships of trust, you're dead in the water; I tried Retroshare for a while but had no friends on it, so had no access to the "core network" through any trusted links. Also, I get mixed signals about the developer attitude to some security aspects of the P2P side of things. For example, they use SHA1 for the distributed hash table, whereas in my opinion one should never use an even partially broken hash for a *hash table*; you never know what exploits are known privately that further break the hash, and should generally assume it's fully broken if your threat model includes adversaries like the NSA. If you're willing to compromise on the quality of the hash that underlies the entire P2P end of the system, I'm wary about your attitude to security overall. This wasn't such a big deal 'til I saw some anons advocating Retroshare as a "usable crypto" solution. Well, it is; if your adversary is a talent-starved rent-seeking quango like the RIAA. If your adversary is the world's biggest circle-jerk of military cryptographers, I wouldn't go there, personally. Maybe I'm paranoid about SHA1? I'm eager for other opinions here. Crypto is an area where the Dunning Kruger only gets worse the deeper you go. On Sun, 17 Nov 2013 16:25:04 +0100 rysiek <rysiek@hackerspace.pl> wrote:
Dnia sobota, 16 listopada 2013 23:19:58 Lodewijk andré de la porte pisze:
2013/11/16 rysiek <rysiek@hackerspace.pl>
So I guess this is my question: does RetroShare's protocol seem solid and sensible? Should we invest time and effort into it?
It's basic concepts are pretty well considered. It's quite like Tor only the first nodes are "trusted nodes" and not just any random one. That said I think the whole RetroShare thingy is shot to hell regarding traffic analysis. That's hard for everyone except the Top Secret level people.
Far as I know there's no deep-communication tactics except store-and-forward for forums. That's some weakness if you ask me. Finding a file based on a hash requires broadcasting the request for the hash, which will likely flood through (part of) the network. Tracing back a flood is pretty easy with a few nodes.
Invest in it? Not a bad thing to invest in. But it's not that special on the crypto/security level AFAIK. I think the whole P2P thing is a bigger deal than the crypto part of it.
Or, more precisely, how it *combines* crypto and P2P. Plus usability: while it's not a staple of it, it is definitely easier to set-up and use than XMPP+OTR over TOR, while the effect is more or less the same -- you get an encrypted, trusted comms channel.
Wonder however if RetroShare gives you plausible deniability?
Hi there, Dnia niedziela, 17 listopada 2013 23:44:14 Cathal Garvey pisze:
Retroshare isn't "like tor", it's "the opposite of tor".
Tor establishes a network of mutual distrust (kinda; you still trust some aspects of the network such as the directory servers).
Retroshare establishes a network of mutual trust, although you can withhold certain details such as whether you or merely a friend known to you is sharing the files you make available (although as mentioned by another this is likely to be traceable with enough network data).
Right.
For high-security work, something like i2p or Tor is probably better. For an alternative to daily, casual internet traffic, Retroshare's *idea* is probably superior; by relying on existing relationships of trust, you can probably get better performance, and data that's relevant to your interests is likely to be nearby in the network because of social networking effects.
Aye.
However, the flipside is without existing relationships of trust, you're dead in the water; I tried Retroshare for a while but had no friends on it, so had no access to the "core network" through any trusted links.
Yeah, that's kinda where I am now. I am wondering if: - it's possible to use my already established PGP/GPG web-of-trust; - it's actually a good idea to do it.
Also, I get mixed signals about the developer attitude to some security aspects of the P2P side of things. For example, they use SHA1 for the distributed hash table, whereas in my opinion one should never use an even partially broken hash for a *hash table*; you never know what exploits are known privately that further break the hash, and should generally assume it's fully broken if your threat model includes adversaries like the NSA. If you're willing to compromise on the quality of the hash that underlies the entire P2P end of the system, I'm wary about your attitude to security overall.
Oh, this is important information, didn't have that. Thanks.
This wasn't such a big deal 'til I saw some anons advocating Retroshare as a "usable crypto" solution. Well, it is; if your adversary is a talent-starved rent-seeking quango like the RIAA. If your adversary is the world's biggest circle-jerk of military cryptographers, I wouldn't go there, personally.
Right.
Maybe I'm paranoid about SHA1? I'm eager for other opinions here. Crypto is an area where the Dunning Kruger only gets worse the deeper you go.
+1 on wanting to hear more about it. -- Pozdr rysiek
2013/11/18 Cathal Garvey <cathalgarvey@cathalgarvey.me>
Retroshare isn't "like tor", it's "the opposite of tor".
Tor establishes a network of mutual distrust (kinda; you still trust some aspects of the network such as the directory servers).
Yeah, Retroshare is Tor except with a different mechanism for finding peers. I don't see how that is the opposite of Tor. The "opposite" of Tor probably wouldn't use Onion Routing. BitTorrent might be closest to the opposite of Tor.
Also, I get mixed signals about the developer attitude to some security aspects of the P2P side of things. For example, they use SHA1 for the distributed hash table, whereas in my opinion one should never use an even partially broken hash for a *hash table*; you never know what exploits are known privately that further break the hash, and should generally assume it's fully broken if your threat model includes adversaries like the NSA. If you're willing to compromise on the quality of the hash that underlies the entire P2P end of the system, I'm wary about your attitude to security overall.
Why does the DHT require a cryptographic quality hash? I agree that SHA1 is too weak to be cryptographic, but a DHT is merely finding chains of other nodes. Worst that can happen is the adversary manipulating you into connecting to them with higher chance. Given the whole friend-to-friend mechanisms I don't see much harm in that. Depends on the plugin that runs above it. I must say that this is exactly the sort of thing I think makes RetroShare risky. Some choices can be conditionally okay. Building a big stack of software lacks overview easily.
On Mon, Nov 18, 2013 at 11:07:10AM +0100, Lodewijk andré de la porte wrote:
Yeah, Retroshare is Tor except with a different mechanism for finding peers. I don't see how that is the opposite of Tor. The "opposite" of Tor probably wouldn't use Onion Routing. BitTorrent might be closest to the opposite of Tor.
You can run RS over Tor. In fact, IIRC RS is in Whonix.
Also, I get mixed signals about the developer attitude to some security aspects of the P2P side of things. For example, they use SHA1 for the distributed hash table, whereas in my opinion one should never use an even partially broken hash for a *hash table*; you never know what exploits are known privately that further break the hash, and should generally assume it's fully broken if your threat model includes adversaries like the NSA. If you're willing to compromise on the quality of the hash that underlies the entire P2P end of the system, I'm wary about your attitude to security overall.
Why does the DHT require a cryptographic quality hash? I agree that SHA1 is too weak to be cryptographic, but a DHT is merely finding chains of other nodes. Worst that can happen is the adversary manipulating you into connecting to them with higher chance. Given the whole friend-to-friend mechanisms I don't see much harm in that. Depends on the plugin that runs above it.
I must say that this is exactly the sort of thing I think makes RetroShare risky. Some choices can be conditionally okay. Building a big stack of software lacks overview easily.
RS could have profited from a less is more approach. E.g. running NNTP could have allowed you to use standard clients. In general I'd much prefer to connect with known (SMTP, IMAP) protocols to localhost rather than poking an unstable, monolithic blob with usability from hell.
You can run RS over Tor. In fact, IIRC RS is in Whonix.
That's one way to screw with the "no filesharing" ban in Tor, which has positive and negative consequences. I do like the idea of layering a network of pseudonymous trust over the Tor layer of mutual distrust, but is that not horrendously slow?
RS could have profited from a less is more approach. E.g. running NNTP could have allowed you to use standard clients. In general I'd much prefer to connect with known (SMTP, IMAP) protocols to localhost rather than poking an unstable, monolithic blob with usability from hell.
This sounds like i2p; a P2P networking layer for applications that need not be routing-aware? Although again; i2p creates a system of mutual distrust whereas Retroshare assumes mutual trust. The advantages and disadvantages of either depend on entirely social factors that are hard to model (see [Cryptography][Law] thread on range of estimates regarding rat-content of hacker community), so as far as the philosophy I'm not prepared to call. Certainly it's easier to establish a route using Tor/i2p than with Retroshare, and it's doubtful you could have true anonymity if your friends can see when you're online and correlate with activities of public identities they may notice through shared interests. But then, that's not what Retroshare is for; it's for creating networks for social and personal use.
Why does the DHT require a cryptographic quality hash? I agree that SHA1 is too weak to be cryptographic, but a DHT is merely finding chains of other nodes. Worst that can happen is the adversary manipulating you into connecting to them with higher chance. Given the whole friend-to-friend mechanisms I don't see much harm in that. Depends on the plugin that runs above it.
Well, the DHT is (if I recall correctly!) used not only for locating peers for but locating files. So, for example imagine the case where an update to Retroshare is offered from within the network: the retroshare devs themselves estimated that to forge a malicious hash would take weeks on consumer end hardware, and therefore that it was an impractical attack not worthy of threat modelling. Leaving aside the fact that your real adversary does *not have to constrain itself to consumer end hardware*, it's the first time I've encountered a "serious" crypto project that considers *weeks* to be "computationally infeasible". This is all ignoring the fact that SHA1 was built by the NSA. Specifically (correct me if I'm mistaken): SHA0 was based on MD5, and SHA1 was then proposed soon after as its replacement by the NSA after some alterations to correct *undisclosed vulnerabilities*. Ahem. So, AFAIK RS is using a hash function redesigned (for all intents and purposes) in secret by *the adversary* which has plenty of publicly known attacks and may well have a critical in-built attack, and relies on this hash to route to the correct file or peer. Once you have a peer's keys, you can keep them and trust-on-first-use, and RS *probably* (anyone wanna check source?) uses and checks signatures thereafter, but if the signatures are based on a SHA1 hash you're back to square one, where a forged hash will fit a valid signature. On Mon, 18 Nov 2013 11:07:10 +0100 Lodewijk andré de la porte <l@odewijk.nl> wrote:
2013/11/18 Cathal Garvey <cathalgarvey@cathalgarvey.me>
Retroshare isn't "like tor", it's "the opposite of tor".
Tor establishes a network of mutual distrust (kinda; you still trust some aspects of the network such as the directory servers).
Yeah, Retroshare is Tor except with a different mechanism for finding peers. I don't see how that is the opposite of Tor. The "opposite" of Tor probably wouldn't use Onion Routing. BitTorrent might be closest to the opposite of Tor.
Also, I get mixed signals about the developer attitude to some security aspects of the P2P side of things. For example, they use SHA1 for the distributed hash table, whereas in my opinion one should never use an even partially broken hash for a *hash table*; you never know what exploits are known privately that further break the hash, and should generally assume it's fully broken if your threat model includes adversaries like the NSA. If you're willing to compromise on the quality of the hash that underlies the entire P2P end of the system, I'm wary about your attitude to security overall.
Why does the DHT require a cryptographic quality hash? I agree that SHA1 is too weak to be cryptographic, but a DHT is merely finding chains of other nodes. Worst that can happen is the adversary manipulating you into connecting to them with higher chance. Given the whole friend-to-friend mechanisms I don't see much harm in that. Depends on the plugin that runs above it.
I must say that this is exactly the sort of thing I think makes RetroShare risky. Some choices can be conditionally okay. Building a big stack of software lacks overview easily.
On 2013-11-18 23:46, Cathal Garvey wrote:
Well, the DHT is (if I recall correctly!) used not only for locating peers for but locating files. So, for example imagine the case where an update to Retroshare is offered from within the network: the retroshare devs themselves estimated that to forge a malicious hash would take weeks on consumer end hardware, and therefore that it was an impractical attack not worthy of threat modelling.
Leaving aside the fact that your real adversary does *not have to constrain itself to consumer end hardware*, it's the first time I've encountered a "serious" crypto project that considers *weeks* to be "computationally infeasible".
This is all ignoring the fact that SHA1 was built by the NSA. Specifically (correct me if I'm mistaken): SHA0 was based on MD5, and SHA1 was then proposed soon after as its replacement by the NSA after some alterations to correct *undisclosed vulnerabilities*. Ahem.
So, AFAIK RS is using a hash function redesigned (for all intents and purposes) in secret by *the adversary* which has plenty of publicly known attacks and may well have a critical in-built attack, and relies on this hash to route to the correct file or peer.
Once you have a peer's keys, you can keep them and trust-on-first-use, and RS *probably* (anyone wanna check source?) uses and checks signatures thereafter, but if the signatures are based on a SHA1 hash you're back to square one, where a forged hash will fit a valid signature.
In view of recent events, I am inclined to distrust SHA1, and even if SHA1 is entirely trustworthy, using it gives NIST and thus the NSA power which it will abuse, and even if one doubts that the use of NIST approved algorithms in one's own project gives the NSA power, or doubts that the NSA will abuse that power, using NIST approved algorithms on default settings gives people reason to suspect that the group, individual, or organization setting those defaults might play footsie with the NSA behind closed doors. For this reason I recommend employing the symmetric algorithms set as defaults by Jon Callas, and the asymmetric algorithms of Daniel Bernstein. Skein in place of SHA. http://blog.jim.com/crypto/moving-away-from-nist.html http://blog.jim.com/crypto/cryptography-standards.html
participants (6)
-
Cathal Garvey -
Eugen Leitl -
Hannes Frederic Sowa -
James A. Donald -
Lodewijk andré de la porte -
rysiek