[dcc2] Multi headers + metadata

[Craig Edwards]

its a symmetric algorithm. RSA etc are public key algorithms. Public key requires secure key exchange, larger keys and more powerful processors, which makes a protocol which does not scale down. There are secure ways to transmit a key for symmetric encryption which do not expose it and are still accessible to lower end implementations (e.g. agreeing on a key between two parties before the actual file transfer, the same way it was done 'in the old days' without issue) I dont believe ive seen a PDA (or cellphone) yet with SSL built into it, but i'll probably be corrected on this, these systems arent what im clued up on ;-) No system should be 'required', all should be optional, but i believe the option for a lower-end encryption mechanism such as blowfish should be provided, and possibly some form of secure key exchange for it if possible.

>> I agree.  For encryption I think we should standardize on the fastest
>> "acceptably secure" encryption method,  blowfish seems to fit this quite
>> well.
>Blowfish is bad. To use blowfish, if I remember correctly, you need to
>transmit the key. The same key is used for encryption and decryption. So
>here is the sample session:
>sender> KEY 1234
>receiver> OK
>sender> DATA kjsdhkjhfdskfhsdhfsdhfdjhrejnfsdjhfieohfsdjhfsdhfsdhje...
>
>Then the receiver decrypts that data using key 1234. Well, you just defeated
>the whole purpose of encryption! You're trying to prevent packet sniffing
>and such. Well, the key is going to be transmitted in plaintext. So the
>packet sniffer can get the key and use it to decrypt the data. All security
>benefits are lost. Hence why asymmetric encryption was created, so you don't
>need to transmit a key/password. If you're using blowfish, there is no
>reason to do any encryption at all since you're not adding much security,
>and you're making the transfer size larger.
>
>Furthermore, SSL does more than just encrypt, it does identity verification.
>When you are excepting potentially dangerous files from people, being able
>to tell who is who is a very good thing. Lastly, I definately want to see
>compatibility with small devices maintained, but not at the expense of
>everyone else. With XML, changing to another format doesn't really harm
>anyone. But, switching from SSL to Blowfish causes a loss in security and
>authenticity. That's a big hit in my mind. Of course though, the encryption
>system was designed to support multiple algorithms. The draft mentions SSL3
>and TLS. More could be added, that's fine by me (though I still think
>symmetric encryption is a bad idea), but I would not say get rid of the
>other features just because some won't support it.
>
>> I'm not entirely sure that we should go with a weak compression algorithm
>> however.  While I personally see encryption as a necessary feature that
>> should be supported by every client, compression I see more as a nice
>thing
>> that should be incoperated into the standard, but not 100% neccessary.
>> Mainly because the lower-memory machines you refer too are unlikely to be
>> transfering files large enough for the lack of compression to matter
>> signifigantly,  or the slowness of it to really matter signifigantly.
>
>The memory availability/processor speed is not the only factor when
>determining about encryption. For example, the JVM that most browsers use,
>does not support encryption, so Java applets cannot implement DCC2. You also
>have legal issues. Why is it that most clients don't implement IRCS (SSL
>over IRC)? US law. If a US developer releases a program containing
>cryptographic code, he/she must ensure that the program will not be
>downloaded in nations on the State Department's list of terrorist nations.
>That is nearly impossible to do. Therefore, US programmers (especially
>open-source programmers who can't afford a lawyer) generally do not release
>cryptographic programs on the web. So basically, what this does is, it makes
>it so virtually all U.S. made IRC clients can no longer exist. Even more so,
>if I remember, encryption is still illegal in China. So by requiring DCC to
>support encryption, 1/6th of the world's population can no longer use IRC
>because it would be illegal for them to have a client that contains
>encryption technology. I agree, encryption is a good thing to have, but it
>should not be required to use DCC.
>
>> I know gzip allows you set how aggressively compressed a file is.  Could
>we
>> allow the client to specify what level of compression it would like?  for
>> example: compression=0...9 where 0 is no compression andn 9 is maximum
>> compression.
>
>Well do keep in mind that not all compression mechanisms allow this. To be
>robust, you want to do something like HTTP, where new compression tokens are
>able to easily be added. Meaning, if tomorrow someone invents an algorithm
>that gives you 99% compression, you are certainly going to want to be able
>to use that instead of gzip! So you need to design it with universal support
>in mind. If you add the compression level, you remove that ability, or at
>least hinder it.
>
>If it were added though, some specifics would need to be worked out. What
>happens if the sender does not oblige? You say you want it to be 2 and I
>give you 7. Does it get dropped? Does it just accept whatever I give? Also,
>you ask for 9, but I can't do 9. My PC is too slow. What am I to do? Should
>I just disregard and send a lower compression level? Or just terminate the
>send? Also, what happens if a client advertises that it will now send using
>4, but the data is actually compressed using 6?
>
>-- codemastr
>
>
>_______________________________________________
>dcc2 mailing list
>dcc2 at dcc2.org
>http://six.pairlist.net/mailman/listinfo/dcc2