>Each friend-to-friend connection is identified by their usernames and a shared secret.
Showstopper. I wanted to ASK how this beats retroshare. But without asymmertic keys you're kinda fd.
>On session establishment, temporary salted authentication and encryption keys are derived from the shared secret by each peer. The current implementation uses PBKDF2-HMAC-SHA512 (10000 iterations) for key derivation.
Please describe in more detail. Form what I read it highly depends in a really good implementation here to provide perfect forward secrecy.
>where secret exchange is made on our servers. Then a code is sent to both you and your friend so that your Teapotnet instance can fetch the secret through HTTPS.
Why don't you just do (authenticated) diffie hellman? Then your Server wouldn't need to know the key.
Sorry but just Form those few sentences i have to assume your crypto is shit and cant be trusted. I'm mobile right now so i didn't look at the source. After that I also probably won't.
Edit: german autocorrect while typing english is REALLY annoying. Sorry for all the typos.
Edit2: What The fuck? Why are there own sha512 and AES implementations? Use openssl! For nie i'd strongly advise Tod avoid until someone more skilled than me has reviewed this. But für crypto Reilly seems horrible.
Yeah, this looks like exactly the type of software you avoid if you actually need cryptographic security. Non-library versions of cryptographic primitives is a serious WTF, that stuff is abstracted for a reason.
What I've seen so far isn't a complete waste, but I'm still reviewing since I have nothing better to do this morning.
So far I've looked at how a crypto-secure schared secret is established with the "original method." It works just as you would expect. The author even made an attempt to ensure that different pairs of peers using the same input wouldn't generate the same secret by xoring the two usernames together. Of course, collisions are easy to generate and I don't see that the tracker's domain is included anywhere, but no serious attacks come to mind through this vector.
I'm not going to bother looking at the Facebook or email methods because the security there reduces to how much you trust your email provider or Facebook.
Hi, I'm the original author of Teapotnet, I want to precise some details.
No cryptograhic library is used mostly for deployment simplicity and portability, but we plan to use OpenSSL in the future (see below).
Xoring the username together is mostly a simple refinement so two passphrases entered for two different contacts or users does not result in the same secrets stored in their profiles. Usernames are part of the authentication anyway.
The current authentication is a simple digest method. It does not garantee Perfect Foward Secrecy. In the future we plan to implement a stronger method using authenticated Diffie-Hellmann (We have to OpenSSL for this). The tracker name is not a part of it as you could change trackers.
> Xoring the username together is mostly a simple refinement so two passphrases entered for two different contacts or users does not result in the same secrets stored in their profiles.
I'm aware of that, but why do you xor the two usernames together instead of concatenate the two full addresses? So that even if two people on different trackers with the same username using the same shared secret contact the same third party, they don't generate the same key?
Edit: Also, why do you avoid asymmetric cryptography? For the same reason you're avoiding OpenSSL?
Concatenating the two usernames is done afterwards to compute the peering (localisation digest). The tracker is not added to the usernames because it should be easy to change trackers without resetting your contacts. The tracker is not really part of your identity like the domain of an email, it's more like a temporary address where your friends know they can reach you.
However, I'm aware of the specific collision issue you highlight. Actually, you must not use twice the same secret for two different contacts (for obvious reasons, since if one of the contacts is somewhat malicious it could guess it and impersonate you by connecting to the other one). Just like passwords, you should never use the same twice. So your example is actually very bad practice for the thrid party.
We don't want to avoid asymmetric cryptography, we want to avoid using a public key system. If you want to use public keys, Retroshare is a pretty good app. The problem is, non-tech people tend to freak out when confronted to public keys, so we wanted something very simple to understand and use.
Saying the crypto is good because he XORs the usernames to avoid collisions in the PSK's doesn't exactly make be believe you're an expert at applied crypto too.
How is this conceptually different than, say, RetroShare?
edit: also, you keep comparing to DropBox, however, I can't find the crucial info - are the data saved somewhere outside the computer or not? If not, why the comparisons with DropBox?
I set up Retroshare on my home server and sent details to a dozen coworkers and friends (all in IT) that had previously used IRC / ftp for similar purposes. Not a single one decided to use it after varying degrees of trying it.
It seems like nowadays all of these services are trying to one-up each other on privacy and promises of good intention. My parents couldn't care less about their online privacy - they were storing their files by emailing them one-by-one as attachments. Anything is better than that system, so Dropbox really did wonders. This solution is hardly a Dropbox-killer, because its not made for the 99% of people who use email attachments to save their files.
I saw an ad for a product Western Digital is coming out with in this realm:
the "My Cloud" product itself is apparently total crap, but the idea will certainly be refined to serve a purpose similar to that of teapot. That is, glorified network file access.
it is impossible to setup and use without deciphering thirdparty guides. and even then it is awkward and painful to use. I wish they would restart with a useable GUI and highly limited but well working feature set.
I'm very surprised by your comment. I'm using it on Ubuntu, my family is still on Macs but uses it too. Everybody without the slightest issue. Install was as easy as any other program (Ubuntu and Mac). True, the UI could be more polished, but it's the tech behind that's interesting when you're interested in privacy.
Give permisson someone to download data on my computer. Simple as that. I don't understand why they compare themselves to DropBox and Google Drive. Furthermore this helps software/game/music/film... piracy.
Frankly, if I imagine a good piece of software for transferring legitimate files, with appropriate privacy/security and a good featureset, it would also be excellent for piracy.
Showstopper. I wanted to ASK how this beats retroshare. But without asymmertic keys you're kinda fd.
>On session establishment, temporary salted authentication and encryption keys are derived from the shared secret by each peer. The current implementation uses PBKDF2-HMAC-SHA512 (10000 iterations) for key derivation.
Please describe in more detail. Form what I read it highly depends in a really good implementation here to provide perfect forward secrecy.
>where secret exchange is made on our servers. Then a code is sent to both you and your friend so that your Teapotnet instance can fetch the secret through HTTPS. Why don't you just do (authenticated) diffie hellman? Then your Server wouldn't need to know the key.
Sorry but just Form those few sentences i have to assume your crypto is shit and cant be trusted. I'm mobile right now so i didn't look at the source. After that I also probably won't.
Edit: german autocorrect while typing english is REALLY annoying. Sorry for all the typos.
Edit2: What The fuck? Why are there own sha512 and AES implementations? Use openssl! For nie i'd strongly advise Tod avoid until someone more skilled than me has reviewed this. But für crypto Reilly seems horrible.