RetroShare

Cathal Garvey cathalgarvey@cathalgarvey.me
Mon Nov 18 08:46:18 EST 2013


> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://cpunks.org/pipermail/cypherpunks/attachments/20131118/8a687b13/attachment.sig>


More information about the cypherpunks mailing list