CDR: Re: StoN, Diffie-Hellman, other junk..

[Asymmetric]

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.