If the client doesn't look at "features" before it sends stuff, it will not be able to be very smart about taking advantage of some future better method. In fact, there isn't much advantage to the server sending anything early - it could just as easily wait until after it's seen the clients request. Failing hard & retrying on a failed reconnect is going to be slower. On the bright side, at least it shouldn't happen often. If you're sending encryption (w/ different auth or keys) from several different streams, how are you planning to indicate which bits go with which scheme?, and which bits are you planning to encrypt and which not? Byte count limits. Basically, you don't want collisions because of duplicated keys or data. This depends on your crypto system, so, for instance, you should not encrypt with one key more than aes, cbc about 2^68 bytes aes, ctr exactly 2^128 bytes more generally, this depends on mode, blocksize, ... This applies across *all* uses of the key - and so you would generally want to use the session key directly as little as possible. (in particular, using the session key for ctr directly would be very very bad.) If you've got multiple streams going already, you should be able to include a fairly simple rekey method with little effort. For instance, as part of the method, you could, up front as part of the method send a per-stream key encrypted under the shared secret. prepend to the first data sent in a payload byte limit, stream key #0 (encrypted under the per-stream key) then encrypt the next N bytes with stream key #0 when the byte limit is reached, prepend to the next data sent in a payload byte limit, stream key #1 (encrypted under the per-stream key) then encrypt the next N bytes with stream key #1 &etc. -Marcus Watts -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
