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