CDR: Re: StoN, Diffie-Hellman, other junk..
Asymmetric
all at biosys.net
Thu Sep 7 18:20:47 PDT 2000
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.
More information about the cypherpunks-legacy
mailing list