At 02:06 09/08/2000 -0700, Bill Stewart wrote:
You can still do CBC with UDP. You might want to look at hybrid solutions, like basic connectivity and voice connections on UDP and separate TCP connections for data transfer, though that may be more trouble than it's worth.
I've thought about it and it's definitely something to keep in mind.. another advantage to doing TCP from my standpoint is that it's easier to multithread. The old version had some problems where on occasion it would stall for a while if it was doing a reverse lookup or something like that, and you wouldn't receive any more traffic until whatever operation was finished. Threading the application allows any of the connections to stall or slow down without taking the rest of the application with it.. and threading UDP isn't nearly as easy. Honestly, with the tools I have available, I don't even know if it's possible. :)
There are synchronization problems you can recover from and ones you can't. You need to stay aligned on the encryption-block barrier, e.g. 64 bits for DES or 128 bits for some other algorithms. If you lose that, you're toast. But if you always pad your packets to multiples of the block size, you don't have a problem with UDP, since packets either arrive or don't. So if you lose a packet, then you've toasted the first 16 bytes of the next, but the rest of the packet and the rest of the conversation are ok. With TCP, you don't lose packets, though you don't always have convenient mechanisms for keeping track of packet boundaries, but you're always going to write in block-size chunks anyway.
Ah ok.. so losing a block will just nuke the entire next block, and then it will recover? I thought it would be a more serious problem than that, but I guess it makes sense that the feedforward wouldn't be able to affect any blocks beyond the immdiate next block. Keeping the packets aligned on block boundaries makes so much sense that it's something I'm doing anyway regardless of this problem. :)
Any symmetric algorithm will have maxed out by 256 bits, and most by 128, though you may want different keys for your two directions. So generating the DH key with 1024 bits is probably enough, though it doesn't hurt much to do 2048 or 4096 - no need for separately generating a key and shipping it. In particular, DH takes advantage of both machines' sources of randomness, which is a major win over something generated by one end unless you've got a good reason for it.
Well, the information I have is that Blowfish takes up to 448 bits, RC2 up to 1024 bits, Mars up to 1248bits, RC5 and RC6 both up to 2048 bits of key material.. is that incorrect? The system currently supports Blowfish, Cast (128 and 256), Gost, IDEA, Mars, Misty1, RC (2, 5 and 6), Rijndael and Twofish for ciphers, and Haval, RipeMD160 and SHA1 for hashes. The user chooses what cipher they want to communicate to the other users with, so incoming traffic can possibly use a different cipher on every connection, while outgoing traffic will all use the same cipher. This brings up another question. My document states that Cast256, IDEA(*), Mars, Misty1(*), RC5, and RC6 are all patented.. * = "Free for noncommercial use." Is there a good repository somewhere with information on all the licensing issues/rules of these algorithms?
Sometimes Mallory _is_ your ISP - even without Carnivore. Public key technology only needs one untampered data transfer to happen, and PGP has a lot more infrastructure for that than trading PRNGs. Signing DH keyparts is a job for public-key signatures.
True, and it is something that I've considered, but I would really like to stay away from any kind of server-based options as possible. The fewer points of failure in the chain the better for this application. I think it would suit me better to implement a public-key algorithm in the application itself, and then have each client maintain a list of all the public keys it has seen and allow the option to the user of signing them with it's own key and then sending them back to the owner. This would allow the same failure-rate where only one transmission needs to occur untampered in order to allow for key validation. Possibly in the future clients could exchange all their keys and then raise the trust level of a public key the more times they see it from different clients. Since participation is entirely voluntary by both parties in both the overall application as well as the key signing/trust parts, then a DoS related to a single user forging a key and then connecting to many clients with many other clients isn't really an issue. The lack of centralized communications means that the malicious user isn't going to have a "master list" to poison, or even an accurate view of all the clients in use. This is all tenative however.. I haven't thought this far ahead until just now. For now, I just want to get the D/H working and the key generation underway. Ah, as an aside to something you mentioned before about using the built-in random functions with Delphi... Borland gives you full source to all the run-time libraries and components that ship with the language, so It's easy enough for me to just rewrite them to be cryptographically strong if I want to do that instead of writing auxiliary libraries.. why I would want to do that however, escapes me just now, but at least I can investigate the methods it is using and see how strong/weak they are.
By saying "I'm going to put this chat server on the Internet".... Crypto has its own special denial-of-service flavors in addition to the regular ones, and Photuris addresses a lot of it with minimal work.
Ah ok..
The "Library GPL" was written to address just that problem. Stallman calls it the "Lesser GPL", because he doesn't like it (:-), but LGPL says you have to distribute source code for the LGPL'd libraries you use or modify (or indicate where to download them) but doesn't GPLize the code you wrote that isn't part of the libraries. So you can use it in your proprietary product without publishing your code, charge money for it, etc.
Ah ok, well I'm no lawyer.. I did look at the GMP license and it still appeared to be worded rather strangely. If the library is linked in to your code then your code must also be open source. If the library is instead loaded at runtime and also is not required for the application to function, it appears the rest of the source can be closed.. I refer to section 6, and section 7 subsection 1. However it's worded, I've found a different math library who's only restriction is that if I decided to charge money for whatever I've written with it, I have to pay the author of the library an amount equal to the cost of one license for the application. A lot more straightforward, and appealing than the legalese of the (L)GPL. See ya 'round. -------signature file------- "'There comes a time when the operation of the machine becomes so odious, makes you so sick at heart, that you can't take part; you can't even passively take part, and you've got to put your bodies upon the gears and upon the wheels, upon the levers, upon all the apparatus, and you've got to make it stop. And you've got to indicate to the people who run it, to the people who own it, that unless you're free, the machine will be prevented from working at all!" -Mario Savio- Founder of the Free Speech Movement.