At 12:45 AM 9/7/00 -0400, Asymmetric wrote <all@biosys.net> :
To make the application more robust, I have started rewriting it to use TCP instead. It is still a peer-peer network, requiring no dedicated servers.. while this increases overhead somewhat, I think it's worth it to keep the system from relying on one particular server, or a group of them.
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.
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. 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.
I have also decided to get rid of the key sharing mechanism, and instead utilize D/H to generate a KEK, then transfer a 4096bit data block from the initiating client to the serving client ..... Now, my main question about D/H is quite simple.. what is considered a "good" size for the prime and primitive used, in bits?
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 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. 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. 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.
An aside is that I'm writing the application in Delphi 5, and the maximum native supported integer sizes are 32bit unsigned, and 64bit signed.. I've been writing a math library of my own in assembler that at compile time will allow you to specify the maximum bitsize you want it to support, but this is proving to be a mind-numbing task.. ;)
Gak! Don't do something that ugly. There are lots of math libraries available, 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. 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.
First, I gotta say.. only been back on the list a day or two and the Signal to Noise seems to have gotten nearly out of hand.. I don't know what cypherpunks has to do with trying to listen in on cordless phone calls, or how to give someone drugs.. but anyway.. something on topic.. :)
It's been high for years - thanks for adding Signal :-) 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." :-) Thanks! Bill Bill Stewart, bill.stewart@pobox.com PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639