Hacker News Reader

Hacker News

Comment by shin_lao | Hacker News Reader

Full thread

shin_lao

Unconvinced.

* Lossless UDP? Is there a reason not to do TCP?

* There is no way to know if the public key is genuine, so the system is very sensitive to MITM.

* The key exchange is inadequate. Why not do DH if it's just to have session keys?

* The system is very easy to brute force as the acknowledgement is based on a known plain text. This is very bad.

A quick glance at https://github.com/irungentoo/ProjectTox-Core/blob/master/co...

I found a potential buffer overflow at line 143. If an attacker sends a large file, what happens?

Making crypto software is not just a question of wrapping a crypo lib (in that case NaCl) with a GUI. There are some tricky security issues as how you use the crypto.

View on HN

>Lossless UDP? Is there a reason not to do TCP?

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.

Your answer raises my eyebrows even more.

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! :)

DH wasn't designed for forward secrecy.

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? :)

I'm referring to this paper: http://link.springer.com/article/10.1007%2FBF00124891

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.

Please explain how DH was designed for perfect forward secrecy...

Please explain why shown plain text in this context would make exploiting weaknesses in their PRNG any easier...

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.

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.

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 I understood their code/doc, the public keys must be exchanged out of band.

So how could the proxy pass for another person?

I'm not sure what you mean by out of band

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

this is pretty much what is needed for this http://en.wikipedia.org/wiki/Web_of_trust

I wonder if the pubkeys could be maintained in a system such as namecoin? [never used namecoin, but it sounds right]

I can't think of a real-time streaming multimedia application that uses TCP. It probably exists, but nobody uses it; it's simply easier and more efficient to deal with lossy formats over a medium that doesn't care about data loss.

(Note that I said real-time. Buffering is fine for one-way communication, lousy for conversations)

For text chat TCP works perfectly fine. IRC and XMPP are the prime examples.

I wasn't talking about text chat.

Actually TCP is a problem for IRC because there's no (standard) way to query how much data has been received (well, acknowledged) by the other end. This is why if you're unexpectedly disconnected from an IRC bouncer while in a busy channel, the replay can still be incomplete.

Lag is also a pig sometimes.

Datagram protocols are just more natural for message-oriented communication.

Reply on news.ycombinator.com