Chat client

Thanks for the input, Anon, Anon, and Anon. Lots of algorithm implementations are available for free, primarily those by Bruce Schnier (sp?) (www.counterpane.com). This includes Blowfish, Twofish, and Solitaire (the latter will probably never ever be used in anything practical).

Anyways, something I didn't mention above, is that this project will be fully opensource and only as a hobby. No-one is getting paid, sorry.

HTML will probably be a good bet for working with displaying the data, and maybe XML if I get around to taking a look at it. I am a bit curious as to whether or not to use UDP as the main means of transferring text from client to client. (Something else I did not post; the server is only used to authenticate clients, and then stores their IP. Anyone that has been auhenticated can get information on any client (get the IP). The clients send the text from client to client, even with or without secure sessions). Any suggestions on using UDP for transferring text only? I think it'd be relatively safe, especially if I bundled it with something like MD4.

[edited by - zackriggle on September 28, 2003 1:54:32 PM]

I highly doubt you''d be dead weight. You''d ad least be someone to talk to, maybe you''d learn a few things from me as I might from you. It''s not like I''m some über-programmer .

Rant:
Does nobody subscribe to GDNet anymore? Is EVERYONE anonymous!?

Well I've pretty much decided that the server will only handle the logons and authentications, and keep a record of these and the IP from which they came. Then, other clients will be able to query this database to IM other users. Thus, we have security (no impersonation) and a lighter load on the server (it only handles contact-list requests). Something else that the server WILL handle, as things get done, is Diffie-Hellman key requests (it will only provide the Prime and the Generator -- P and G).
Other than this, everything is client-to-client. There is hardly any server intervention at all. As for abnormal disconnections, I'll probably implement a heartbeat (keepalive) somewhere along the line. Both ends of the connection (just between client and server) would send a heartbeat (1 byte or however many are required) every N seconds (most likely 1-5). This way prevents us not noticing abnormal disconnections.

Edit:
The application protocol will be, even though this will be open-source, proveded in a .DLL file for others to use.

Also, is there a standard way to, when using Diffie-Hellman, get larger values out of the 'secret' that is provided? Right now all I can think of is to use 64-bit integers to do the calculation to get the 'shared secret', and do this several times to get a total 'shared secret' of 512 bits (max encryption I am going to support). Another, less important question is whether I should use a block-cipher like Blowfish or a stream cipher (none come to mind)?

==================
My (soon-to-be) Cherished Cookie of Appreciation:

-- MattB - WinSock advice --
-- Sneftel - how 'extern' works --
-- LessBread - Hooks ans Shared Memory --
-- groby - safe assumed MTU size --

[edited by - zackriggle on September 29, 2003 7:50:15 PM]

Block ciphers are tha bomb =).

What you probably want to do, to spare on trafic, is generate a big assed RSA key, something like 2048 and up, and have the clients give the server an (for instance...) AES key.

From that point on, the server could comunicate with the client with AES(much faster then RSA), and the client could comunicate with any other client, would just need to request the correct AES key from the server, and send data to the target client encripted with it.

This would be peer-to-peer chat, would save bandwidth on the server, of course if you implemented channels, you'de have to either chose the client with the largest amount of bandwidth, to serve the channel, or the server would have to serve every channel.

You'de get something like a certification entity, the server, and clients.

Anyway, i'm doing a secure chat program, it'll be fully encrypted, this subject interests me =).

EDIT:
Btw, you should distribute the server key along with the client software(my opinion), this way you don't have to worry about key distribution(and no $$$ spent), just software distribution.
If the client connects to the server, to request a public key, to transfer the client's AES key, a man in the middle attack might be possible. So you need a certificate for the server's public key(you pay to have one of these) for the client to confirm, and then you transfer your trust(and funds) to the certification entity. In the end it's all about who you wanna trust(pay!).

[edited by - Cypher-PT on October 6, 2003 6:46:44 AM]

     Sorry, I must've said something wrong, or misinterpreting something. The server only stores the P and G elements of the DH key-exchange (not actual public keys). The reason that I have to do multiple key exchanges is that I cannot (without some extensive work) use integers larger than 64 bits. Speed is not a problem for encryption... I will just use the same tactics as AOL does to defeat latency: make the message appear on the sender's screen instantly.
     However, on a LAN, latency will not be a large issue and with a fast cipher like Blowfish, encryption speeds should not be effected much, either (ALL of the computers on the entire network are running 600Mhz PII or PIII processors).      As for distributing the public variables with the software, this may lead to someone making a dictionary of the most likely keys to be generated given the Psuedo-Random Number Table that will be distributed, hence lowering the overall security. Changing the values stored on the server daily, or even weekly, will keep these attacks out of the way. The chance that two clients start an encryption session with different P and G values is very slim.
       If anyone has seen or (better) implemented a library that is capable of using 256- to 448-bit integers, please drop me one at: zackriggle (at) yahoo.com
     As for Client<->Server encryption, this was a thought of mine, but it is not a large concern of mine, although it may be added later on. So far the only thing that is actually planned to be encrypted like that is logon information.
Man-in-the-middle attacks are a high risk to this sort of software, especially on switched networks where on can filter all of the information that passes between two points. A certificate system like the one described by you may be implemented at a later date, and should not take much to integrate. From what I understand, I get a 'certificate' from the server, then ask another source to validate the certificate for me? This involves more complexity, yes, but also more security and I learn quite a bit more.
Any more suggestions?

[edited by - zackriggle on October 6, 2003 6:33:32 PM]

"The reason that I have to do multiple key exchanges is that I cannot (without some extensive work) use integers larger than 64 bits"
There are a ton of public/free/open source multiple precision math libraries out there... get one.

"The server only stores the P and G elements of the DH key-exchange (not actual public keys)"
DH is, like RSA, also vulnerable to man in the middle attacks, you also need to certificate the keys, before exchanging.

"As for distributing the public variables with the software, this may lead to someone making a dictionary of the most likely keys to be generated given the Psuedo-Random Number Table that will be distributed, hence lowering the overall security. Changing the values stored on the server daily, or even weekly, will keep these attacks out of the way. The chance that two clients start an encryption session with different P and G values is very slim."
If the keys are generated using pseudo-random number generators, they are not secure(it's just that simple). If you don't include them with the software one can still just sniff them while comunicating with the server. Either way it's insecure, and it's NOT because it's distributed along with the software, it's because the keys are weak enough to permit a brute force attack and are predictable because they use pseudo-random numbers in the first place.

"From what I understand, I get a 'certificate' from the server, then ask another source to validate the certificate for me? This involves more complexity, yes, but also more security and I learn quite a bit more."
In the end there you got it wrong, a client connects to the server, asks for it's public key, and to see, if that key isn't from another person 'in the middle', the client checks in another server, a so called, certification entity, if that public key is indeed the one from the original server. For you to have that, you'de need to buy a certificate from that company.

If you are serious about the security of your software, you should pay close attention to all the details, from what i've seen you seem to be using the 'less effort' tactic eheh. You need big numbers, but they are hard to program, and you don't wanna look for a MP lib, so you restrict the number size(wrong). Instead of using your own random numbers generator(more work), you use a pseudo random one(wrong).



[edited by - Cypher-PT on October 6, 2003 8:30:24 PM]

I don't know what really counts as a 'real' random-number generator. The one that I am using (dev'd by me, I consider it a PRNG) tracks the mouse for 5 seconds, involves the system time, user name, registry hive size (ms-specific), the last 3 webpages visited (ms-specific). I have not found anything else that is almost completely random. I have thought about polling the number of free bytes on the system drive and used bytes in a certain directory, as well as slack space on certain files.

Thanks for the info on certificate entities, that may be something that I look into, it may not. It's a small bit of trouble involving a 3rd party on a (possibly internet-less) LAN . Is there an established protocol for certificate transfer? Can any host be a certification entity? Are there any open-source projects or websites that give in-depth examples or documentation on certification entities? Just a few more questions to be spun into the web.

Also, is it possible to use other peers to be certification entities? If so, this will save me money that 1) I don't have and 2) I don't want to spend. If this is possible (I'm assuming it is) then you would need multiple men-in-the-middle of the connections, right? This would also prevent any sort of DOS or DDOS on the certification server, unless someone manages to flood the LAN.

Thanks Cipher-PT, I do need criticizm. (criticism?)

[XtaC]

[edited by - zackriggle on October 7, 2003 2:14:34 PM]

Your random numbers generator, IS, what in cryptography ppl call, a true random number generator, because it envolves human factors, and those can not be predicted. That''s good =). You''re using more then enough factors, just the human ones are enough. But the amount of entropy it produces(i imagine it produces 64 bits of entropy) has to be large enough for a brute force attack to be ''impossible''.

About the certification, this is just a big name, first, ppl think of certification entities as those big assed companies, with big assed connections, that do certification on a world wide basis. But what they do basicaly is, they have a huge public key, for security, ppl use their key, to send an encrypted request to the server, the request is a question, they send a key and a name, and they ask the server if that key belongs to that name. That''s it. You can have your own host to do this. I belive there might be some standards about certification i just never really loked them up, because i don''t plan on needing them =).

But if you can see the ppl you''re talking with eheh(LAN), you can skip all this, just distribute the public keys by hand, write them on a piece of papper/floppy/zip, and give them out. The MD5 secret service came up with the idea of public keys, and it''s belived a NSA mathematician came up with it even before, because they needed to transmit keys that they couldn''t even transmit through secure lines, because if one of those was compromised, that key would also be. They used to have these key distribution missions, where this guy with a suitcase coffed to his wrist, would have to travel across country to give a secret key.

So if you can see the ppl in the LAN and actually talk to them, you can just distribute the keys personally, but that''s a bit boring =). You can also, have public keys, and just get up from your chair and ask out load "who''s key is this?" eheh.

And i''m not sure, i think it''s criticism, but you should certify yourself with a dictionary eheh.

Public key encryption was created to solve a big problem in cryptography, key distribution without any prior secrets. And it didn't because of man-in-the-middle attacks.

Currently you can't communicate with someone securely without a prior secret. If there is a chance that someone is 'in-the-middle', there is allways a chance, even if some times a really remote one, that a key is going to be captured/tampered with.

Ex: If you have a public key, and decied to send it to someone, so that person can send encrypted data to you, that key can be captured 'in-the-middle' and be switched by another. When that someone tries to send the data to you, the 'middle-man' can decrypt the data, because the data is encrypted with his public key, and encrypt it again with the public key you tried to send in the first place. The 'middle-man' can read everything, and no one can tell the diference.

Ex: If you send your public key, and a digital signature of yours, the 'middle-man' can't do anything about it, but now there is the problem of FIRST sending your digital signature, so that the end person can confirm your message, WHEN you send that digital signatura, the 'middle-man' can capture it, and switch it with one of his own. So when you send the public key with your signature, he can just change the key, he is not able to make your digital signature, but he doesn't need to, because the end is expecting the 'middle man's' signature, so he puts his one instead, and now he can again read everything.

Ex: If you send a public key with a signature AND a certificate of the signature(now you don't have to send the signature first, it will be confirmed in the certification entity), everything is the same, the 'man-in-the-middle' can just, change the public key, and use one of his signature-certificate pairs, when the end user tries to confirm the signature and the certificate using a certification entity, it has to request the public key of the certification entity(i think windows cd's already come with certification entities public keys, to avoid this), to send the question encrypted so no one can change it. But again, when requesting the public key of the certification entity, the 'middle-man' can intercept, put his own public key, receive the request himself, and not even allownig the certification entity to answer, he answers himself however he wishes, and again he can now read everything.

NOW, should we panic? Nop! When we talk about 'middle-man' we're talking about someone who managed to compromise a ISP router, a ISP backbone, or some worker at one of these targets has to be dirty and be doing this, this is VERY hard to come by, because these kind of computers are very secure. Is not easy being a 'middle man' and when stuff is certified, it's even harder.

With the sugestion i gave, about distributing the public keys with the software, is the same thing, a 'middle-man' can just as easly intercept each packet when we're trying to download the software, and change it with packets from a piece of software with a diferent key, he can even insert virus, key loggers, backdoors, in the software.

The advantage is that if you buy a cd with original software that comes with a key, there is no way for a 'middle-man' to spy(because there is a pre established secret, the key in the cd, he can't intercept the key, because we already have it, and the only thing passing the cables is going to be encrypted packets), or if we host the software in say... 10 places, the 'middle man' has no way of knowing where we are going to download it from, SO he has to control 10 points, he can do this just from one computer, but it has to be a computer very close to you, like your ISP for instance, so that all trafic from you and to you, comes through there. You can actually do the same with public keys, put them up in a lot of public places, and it's harder for someone to switch them. If you have multiple ISP's, it can make the 'job' for the 'middle-man' even trickier.

Bottom line, without a pre established secret, you can't be 100% sure your secure.

[edited by - Cypher-PT on October 9, 2003 4:09:45 PM]

Very well put Cypher. This does make me think a little bit, but the chances of someone managing to get onto a network switch so that they can monitor\switch the information on a LAN is slim-to-none, even if it is possible. The chance is either better or worse on a corporate LAN, and definately lower on a school LAN (Because in a corporate building, all you have to do is know your shit and act like you are the last line in fixing an uber-problem. In schools, and smaller businesses, this is all much less likely to happen because everyone knows everyone else.)

But, of course, if a man DOES get in the middle, there is little to stop him. Especially if he has access to the full source-code of the project (which everyone will)--- there would be no security through obscurity.

I did get a multi-precision math library, and I will probably try to get a feel for how it works and read the docs tonight... too much to do at school .

Other than that, the Network API is about halfway done (I am really lazy... I think about coding all day, then get home at the computer, and Half-Life for an hour ). I am trying to decide if it would be a big performance difference if I moved from using empty dialog boxes to custom-made windows with their own classes for Socket notification. I am also thinking about pooling multiple sockets onto one window instead of giving them each their own (200+ windows is a baaaaaaaaaaaaaaaaad idea).

[Xtac]

[edited by - zackriggle on October 9, 2003 9:40:29 PM]

About the windows =) yeah it is a bad idea to have a window to each socket and it''s also a bad idea to have a thread for each socket, not only does it have a ''small'' limit in windows machines, a couple of thousand if i recall correctly, but it also is slower then just using the select funtion, or, if you want to make it über ^_^, using completion ports with overlapped structures.