At 15:08 09/07/2000 -0700, Bill Stewart wrote:
Servers are the price of scalability. The nice thing about ICQ and similar instant messaging applications, unlike IRC, is that the server only tracks who's on and where, and doesn't carry the actual communication traffic between users. Obviously this is for one-to-one conversations between two users rather than IRC's everybody-to-everybody model. Another option in this space is the everybody's-a-server model, like Usenet uses. Servers also offer the benefit that it's harder to tell who's talking to whom, unlike point-to-point conversations, but they do cause risks from compromise and downtime.
Right.. I consider the benefits to outweigh the costs. I am keeping the protocol robust enough that if you wanted to implement a server on your own, you could probably do so with minimal impact to the clients themselves. When finished, you'll be able to add servers just as you do other users to your "buddy list" if you will, and communicate with a larger group that way. Inter-server communications is not restricted either, but it's a ways down the road.
everyone must maintain an active TCP connection to everyone else..
That's a MAJOR downside. Most operating system and programming environments limit how many open TCP connections you can keep, typically <20, so this limits the sizes of communities you can maintain. Also, if you have TCP connections you need to write code to handle having them go up and down at unplanned times, while UDP just dribbles in. On the other hand, TCP sessions are good for data transfer. Voice over TCP is a sketchier issue - the problem is that the best way to handle lost voice packets is just to ignore the noise, as opposed to waiting for the retransmission to arrive and speeding up or delaying talk until you've caught up.
Yes.. I understand the differences in TCP/UDP pretty well, and their strengths and weaknesses. I've done extensive programming using both, and have decided to go with TCP. I do however have two points to bring up with the beginning of this section of your reply. 1) I've never encountered the 20 socket limit on any OS in recent memory.. and many applications open more than this on a regular basis. 2) The target audience of this application is very small, and currently restricted to Win32 users because it is written in Delphi. Before long Delphi will be available for Linux, and cross-compiler compatability will have to be tested, but it is a big selling point with Borland/Inprise. When Kylix (Delphi/C++ Builder on Linux) is available, I am keeping my fingers crossed that it will run well on FreeBSD, since I refuse to touch Linux with a ten foot pole, but have several years experience not only with Delphi, but with Administration of FreeBSD as well as NT based boxes. I agree that voice using TCP has the drawbacks that you mentioned, however, because of the other existing requirements such as CBC and File Transfer, it is required that you have a reliable connection to get even the basic functionality of the program to work. I'd rather have a delay in hearing the voice messages until the packets have arrived than decrease their security by using ECB.
Your issues about ECB mode with UDP are good, though. The alternative is to use CBC mode and trash the next couple of packets after the lost/damaged one - CBC does self-recover. This is ok for voice; may or may not be for chat.
CBC does self recover yes, if bits are flipped that should not be flipped. According to AC, a one bit error will cause a corresponding 1bit error, as well as mangling the following block.. but subsequent blocks will be OK. However, it states very clearly that receiving the wrong number of bits in the stream will destroy the rest of the stream beyond repair for the decryption end, and that makes sense. If a UDP packet is lost, then the rest of the stream is screwed and must be reinitialized. Since the only way around this problem (besides using EBC) is to write my own connection-handling on top of UDP; I instead choose to let the OS handle this for me, in the form of TCP. To quote Applied Cryptography, 2nd edition.. p195, pp5 "In CBC mode, a single-bit error in the ciphertext affects one block and one bit of the recovered plaintext. The block containing the error is completely garbled. The subsequent block has a 1-bit error in the same bit position as the error." ... p196, pp2 "While CBC mode recovers quickly from bit errors, it doesn't recover at all from synchronization errors. If a bit is added or lost from the ciphertext stream, then all subsequent bits are shifted one bit out of position and decryption will generate garbage indefinitely." I assume that losing an entire block worth of bits will cause as much havoc as losing just one bit would. If that isn't correct, I'd like to hear it..
The rule of thumb is that you need at least twice as many bits of DH as you need of secure session key for your application, and you need at least as many bits of DH as you would need for RSA. You wouldn't want to use fewer than 1024 bits of RSA these days, so don't use fewer than 1024 bits of DH. That's enough for multiple 128-bit keys. There are various format proposals for turning the DH key into a session key, like using Hash(DHKey,YourIP,TheirIP,maybe-a-counter-or-Salt). 4096 may be overkill, but it depends a lot on how often you'll be rekeying and how long you're willing to watch the CPU crunch to set up a connection.
The D/H is going to be used just to generate a key to securely transfer a 4096 bit key for use in symmetrical crypto routines later in the program, for actual encryption of the chat/voice/file data transfers. Using 1024 bits of D/H is fine to generate a key-encryption key to just transfer the 4096bit key. I chose 4096 because it's large enough to be used in any symmetric crypto algorithm to max out it's key length.
The bigger risk, though, is the quality of random numbers available for seeding your DH keys. Don't even DREAM of using Delphi's builtins, if it has them - go find good crypto-quality-randomness work to reuse, unless you know you'll only run on Linux where there's /dev/random. At least use sound-card noise or user-entered mouse tracks to help. Lots of "secure" systems have been cracked by cracking their random seeds.
Of course. ;)
If you don't have any other keying mechanism, you need to worry about man-in-the-middle attacks. A simple approach is to use PGP public keys to sign the keyparts; that lets you reuse all the PGP infrastructure. There are alternatives, at least for voice, like reading the bits of the shared keys to each other. See the PGPFONE docs for much discussion on user interfaces - and think about how much of their code you can rip off\\\\\\ reuse.
Well, truth be told, everyone knows that there is the problem "If Mallory is God.." which in this world simply means, if Mallory is your upstream you're in some serious trouble. He could just as easily intercept the PGP keys and replace them with his own if they didn't already exist on the server.. this would cause problems for keys signed outside mallorys realm, say if you could distribute your key outside his available channels... however, if you could do that, you could just as easily trade a PRNG and a list of seeds, or even discuss whatever it is you mean to discuss over a cup of coffee.. :) There comes a point of diminishing returns in trying to defeat the mallorys, where instead of making the problem harder for them, you just replace it with an equally hard/easy problem of a different nature. I'm as paranoid as the next guy, but if mallory exists (in a given scenario) and he is in a position to intercept/forge a D/H exchange, then chances he is in a position to intercept/forge his own PK are highly likely.
Also read the Photuris internet drafts - there's a lot of experience on denial-of-service attacks that they've incorporated, and it doesn't take much work to prevent most of them.
Ah, sorry.. how did we get on the topic of denial of service?
Gak! Don't do something that ugly. There are lots of math libraries available,
Hey, I tend to find asm totally the opposite of ugly. I've been writing it for years and have become pretty proficient at it, and my solutions are usually quite fast and elegant. But, I have found a library I am going to be using instead.. the FGInt library.
such as the GMP Gnu Multiple Precision integer package. Depending on how Delphi feels about calling C routines, the most you should need to write in assembler are some little wrappers to format the function calls, and hopefully you don't need to do that.
Delphi can call C routines no problem, I have two problems with GMP that however have nothing to do with Delphi.. First, It's GPL'd, or under a modified version of the GPL. I find the GPL to be distasteful and it forms a barrier more than a bridge to continued software development. The reason for this I think is pretty simple; the GPL (I refer to the classic GPL.. I am not sure of modifications to it that may have been made for it's application to GMP) has made it excruciatingly clear that any program or library using any GPL'd source code must itself be open source, and cannot be sold for profit, but only "at-cost". This represents a very "scary" proposition to professional developers such as myself, who are used to being paid for our work, since it basically states that any person can just come along, take a copy of our source code (which may in and of itself contain anything analogous to a "trade secret"), modify it and release it under a different name. It also bars me from ever releasing a for-pay version or revision of the software based on GPL'd code. I'm not in the support business, and any examination of the stock market would make it pretty obvious that those companies that claim they are in that business aren't doing so well. I much prefer the BSD license which allows you to take, modify and use the source code within, and sell it or distribute it without source code if you so choose, provided you include the existing copyright for the sections of code you have used. It gives the developer more freedom over how to distribute his/her own code, and incidentally allows people like myself who aren't in the support business and don't want to be the freedom to continue paying the bills by doing development on our own terms. Sorry for the rant.. I'm a big fan of the Free Software movement, as well as the Open Source movements.. I am however mature enough to realize that there are situations when either one may be inappropriate, and I'm a far bigger fan of freedom than I am of free/open. I believe that if you want to make your source code open and free, then you do so without restrictions.
Also, some versions of the RSAREF libraries had Diffie-Hellmann code in them, as well as multiple-precision integers.
Other chat and messaging systems have been written. Check out GALE at gale.org, and look through the Cypherpunks archives for encrypted IRC and DCC variants. Don't let that stop you from coding, but do steal code rather that writing from scratch when you can.
Ah, but that really detracts from the joy of a lot of it.. :) The only parts I'd steal would be parts that I'm finding difficult to do, like the large math libraries.. and that takes all the fun out of learning for yourself.. :) Far from inventing the wheel though, I will use libraries/snippets that stand up to my testing as well as my scrutiny of their license.. I want to get a version working now (without gpl-like restrictions) and then I probably will go back and rewrite every line myself that I have obtained elsewhere, just so I know how it all works, I am free of licensing restrictions, and I can implement bug fixes/features without worrying about maybe breaking something I didn't write. You know how difficult it can be to understand code written by other people, I'm sure.. ;)
It's been high for years - thanks for adding Signal :-)
I'll try and continue. ;)
Listening in on cordless phones can be a legitimate cpunks kind of topic, though it's been discussed in the past and this was probably just a troll or a clueless newbie. As far as giving people drugs, the standard Cypherpunks approach is to say "That's a hardware problem" and then discuss whose Palm-pilot digicash system you can use for payment, though there has also been crypto protocol work like "The Cocaine Auction Protocol" on how suppliers and consumers can find each other without interference by non-participants, or building conferencing systems for ravers where the server operator provably doesn't have anything subpoenable that would indicate which chatters were discussing where to get drug X at event Y. (There are also noisier Cypherpunks approaches to drugs, like saying "Jim, yer off yer medication again" or "smells good, got any more?" or "He's obviously smoking something *very* good and not sharing" or "No, in a geodesic gift economy you really *might not* charge for drugs." :-)
hahah.. of course.. well, again, sorry for ranting above a bit and possibly contributing some to the noise.. I'll be around, but for now, there is another window open with code crying out to be written... ;) Take it easy. -------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.