Hacker News Reader

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.

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]

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.