>There is no way to know if the public key is genuine, so the system is very sensitive to MITM.
If you want to add someone you need their public key (their id) which is 32bytes (It's small because we use ECC instead of RSA). Unless someone somehow replaces the key (your id) when you give it to your friend the system should be secure.
>The key exchange is inadequate. Why not do DH if it's just to have session keys?
The key exchange is designed that way because we want forward secrecy.
>The system is very easy to brute force as the acknowledgement is based on a known plain text. This is very bad.
Can you please elaborate on this. If you are speaking about the the second part of the crypto handshake I can assure you that the fact that the plaintext is known is not a problem.
>I found a potential buffer overflow at line 143. If an attacker sends a large file, what happens?
The function read_packet is hard coded to never return something bigger than MAX_DATA_SIZE.
I ask why you don't use DH and you answer "because we want forward secrecy". DH has been designed for perfect forward secrecy. Therefore I fear we might have some sort of misunderstanding here.
You don't want to permit known plain text attack as "in depth defense" approach. If there is ever any weakness in your software, you want to make it very hard to exploit it. Known plaintext will make exploiting weaknesses in your PRNG very easy for example.
As for your last comment... If someone ever changes the behavior of read_packet, you're dead. So I'm sorry, but you have potential buffer overflow. Think in 4 dimensions Marty! :)
True, my usage of designed was a little bit liberal here. Mr. Diffie is one of the authors of the first paper to introduce the concept of PFS, but the DH key exchange algorithm hasn't been designed for PFS but rather for 0-knowledge key exchange.
Nevertheless, I stand by my remark regarding the pertinence of DH in that case.
DH is also not a zero-knowledge key exchange algorithm. I think what's confusing you is that DH (a) is a useful building block for forward-secret protocols and (b) generates secrets that often require zero-knowledge proofs.
I'm not sure what paper you're referring to but wouldn't be surprised if Diffie's name was on one of the first "forward secrecy" papers; that stuff is/was kind of Whit Diffie's beat (not "privacy" per se, but the higher-layer implications of public key cryptosystems). But Diffie-Hellman predates any formalized notion of forward secrecy by something like 20 years.
DH is zero-knowledge in the sense that the two peers have no knowledge of each other, and yet share a knowledge at the end.
Again, I admit my word usage is a little bit liberal, but although I haven't done serious crypto for a couple of years now, I have the strange feeling you are nitpicking. Is it just a feeling? :)
Curiously, although I've always preferred DLP-based crypto, I actually never implemented any. So I gladly admit my knowledge of DH key exchange might not be as profound as I would like it to be.
That's not what "zero knowledge" means. In the context of STS or, more generally, DH, a ZKP is something you'd add after DH, to verify that one party or the other had arrived at the expected DH result.
I don't think I'm nitpicking: I see where you're coming from but I think you might be entirely wrong.
I don't know what it means to "prefer" DLP crypto. Over what? I just don't understand what you're trying to say with that last graf.
Well, if you exchange your keys via DH and start using that key to cipher the communication, you're going to find out very soon if you exchanged the key properly, won't you?
In essence, once you've agreed on a key you won't keep it to yourself (although you could, in theory). But am I missing the point? Are we talking about two different things? I'm talking about ZK from a mathematical point of view, you know, the cavern, the treasure, the two paths... (if you know this layman example about ZK)
Unfortunately I cannot go into details, but what I meant about my preference for DLP is that although I was mathematically more attracted to DLP based algorithms (when it came to asymmetric cryptography) I didn't really have the chance to "play" with them and spent more time with RSA.
So it's probable my knowledge of the DH key exchange algorithm is imperfect and last time I wrote crypto it was very mundane (it was using RC4, that's saying a lot!), so maybe I should just refrain from commenting about crypto.
SRP is a good example of DH with a bolted-on ZK system; the client and the server arrive at a key using a hash of a password as, effectively, the basis of a DH parameter, then use a hash-based zero-knowledge proof to "authenticate" each other.
tl;dr There is a buffer overflow in read_packet(). See below.
edit Shit, i'm wrong. I missed this line 599 of Lossless_UDP.c:
if (size > MAX_DATA_SIZE)
return 1;
That is the only section that verifies the size of the memory being copied, which is still dangerous. Every memcpy should enforce the size being no greater than the size of Data.data, and not rely on .size having been previously set properly.
I'm not sure if you understood what MITM(man in the middle attacks) actually means.
I will give you a high level example of what he is talking about. your software displays a public key to perform encryption. what 'the NSA' can do is put a proxy (or use your isp) in between you and the person you are sending data to. Then they can pose as the person you are sending data to by hosting their own public key to both you and the person you want to send data to. now they can decrypt information that you send, and then encrypt it with their private key and send it to the other person. NOW THE NSA CAN SPY ON YOU USING YOUR APP.
man in the middle attacks can get much more complex than that, but this should help you understand what is going on.
If you are attempting to write security software you should really at least learn crypto AND networking. it seems like you have not accomplished either of these.
If you mean that it is communicated over TCP/IP(what i gathered from reading the doc), what is stopping someone who has access to whatever is connected to your IP from redirecting traffic to that port in order to do what was already discussed.
if you mean that it is shared in person off the internet, then what is the point of this program. Diffe Hellman, ECC, zero Knowledge proofs are all dependent on the discrete log problem being hard, so you might as well just start broadcasting to their ip with the key that they gave you in person instead of going through the trouble(and increase in vulnerability) of trying to establish that the person is who they say they are. maybe I'm wrong but I don't think that math is wrong.
in any case, I feel like the problem for this program stems from the fact that validating the IP address of the person is much more complicated than it seems. Its pretty much the reason centralized databases are needed for connections between people(those are bad things in our world now).
Thanks for that. I saw a post on some chan, quickly browsed the source and thought you'd just exchange public keys via unauthed connection.
The reply does make sense, so I'll take a look at the source again and check your answers.
You should have posted this at the chans, where I voiced some similar objections.
Hole punching.
>There is no way to know if the public key is genuine, so the system is very sensitive to MITM.
If you want to add someone you need their public key (their id) which is 32bytes (It's small because we use ECC instead of RSA). Unless someone somehow replaces the key (your id) when you give it to your friend the system should be secure.
>The key exchange is inadequate. Why not do DH if it's just to have session keys?
The key exchange is designed that way because we want forward secrecy.
>The system is very easy to brute force as the acknowledgement is based on a known plain text. This is very bad.
Can you please elaborate on this. If you are speaking about the the second part of the crypto handshake I can assure you that the fact that the plaintext is known is not a problem.
>I found a potential buffer overflow at line 143. If an attacker sends a large file, what happens?
The function read_packet is hard coded to never return something bigger than MAX_DATA_SIZE.