4 ms·

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

by 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.
lawl 13y ago
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. Sorry.
- bren2013 13y ago
  I said they made an attempt in the right direction from the small bit of code I'd deciphered and outlined some unaddressed problems. I offered a critique of their code--I didn't praise or damn it. I apologize if there was any confusion.

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.

lawl 13y ago

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

bren2013 13y ago
I said they made an attempt in the right direction from the small bit of code I'd deciphered and outlined some unaddressed problems. I offered a critique of their code--I didn't praise or damn it. I apologize if there was any confusion.