6 ms·

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

by lawl 13y ago

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

tga_d 13y ago
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.
300bps 13y ago
You sure sound angry over a quick review of a new open source project done on your mobile phone.
bren2013 13y ago
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. I'll keep updating you guys if anyone cares.
- alupo 13y ago
  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. Thank you for your interest in the program !
  - bren2013 13y ago
    > 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?
    - alupo 13y ago
      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.

by lawl 13y ago

tga_d 13y ago

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.

300bps 13y ago

You sure sound angry over a quick review of a new open source project done on your mobile phone.

bren2013 13y ago

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. I'll keep updating you guys if anyone cares.

alupo 13y ago
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. Thank you for your interest in the program !
- bren2013 13y ago
  > 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?
  - alupo 13y ago
    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.