I refer to multi-streaming as the ability to send two or more streams of some unit of data (block, byte streams) in one established association/context. SCTP is an example and the protocol I was thinking about when this question came to mind. How could I efficiently secure data sent over multiple streams?

What I see in many documents is something equivalent to N handshakes have to be performed for N streams. This seems to be suggesting each stream is independently secured. A counter example would be to add multi-stream-over-one-stream to TLS instead of naked TCP. But that would not include independent loss/order recovery.

What I was wondering about is making security more efficient over multi-streaming (like SCTP) by first securing one stream then using that stream to secure more streams without the full handshake. If stream 0 is already secure and a sender wants to start sending some data over stream 1, my idea is to generate a random key and send it over stream 0 with info that it is for securing stream 1. But is this safe even when stream 0 is already secure?

I was thinking of using SCTP (for other reasons) and do security management over stream 0 and data over streams 1 and up. EDIT: The idea is to speed up starting to send data by the sender generating a key for a new stream X (X > 0) and sending that key over stream 0 and then sending encrypted data over stream X.

This question is the inverse of Has networking using multiple “unrelated” connections to share an encrypted data stream been researched? The streams I want to secure are related by being part of the same association with no intent to bond them (they would stay independent).

  • I don't see a problem, under the assumption that the software on both endpoints is prepared to securely process and manage that secret. If say HTTP was used, XSS or similar attacks against the endpoint could trick it into revealing secrets transfered in the application layer. You need to make sure the new secret isn't accessible to untrusted code. Note that for PFS you still need proper key management for this new secret, but if the first layer already is using PFS (say ECDHE key exchange) then simply securely deleting the secret afterwards will preserve PFS for the second channel. However, I
    – Natanael
    Commented Jun 3, 2015 at 11:31
  • i was planning to use JSON and send the key in hex or base32 or base64 or base85 but i don't see an issue with that.
    – Skaperen
    Commented Jun 3, 2015 at 11:43
  • i often send shared secrets over SSH to tranfer files between distant servers (avoid more SSH logins) with: skaperen.s3.amazonaws.com/tarnet
    – Skaperen
    Commented Jun 3, 2015 at 11:56

1 Answer 1


[...] my idea is to generate a random key and send it over stream 0 with info that it is for securing stream 1. But is this safe even when stream 0 is already secure?

You can do that legwork yourself, but I don't think you'll have to.

RFC 3436 says that you can do a full TLS handshake on the first stream and then an abbreviated handshake (using TLS session resumption with the session ID from the full handshake) on the other streams.

Would this work for you?

Further reading

  • this may work. my hope was to skip TLS on streams >= 1 and just go straight to CBC after "sharing" the cipher key over stream 0.
    – Skaperen
    Commented Jun 5, 2015 at 12:34
  • 1
    Then you'll have two crypto setups to worry about. And crypto is hard. So why? Do you think your way will be faster? RFC 3436 also allows this: "In networks with large round-trip time delays, it may be favorable to perform a number of full handshakes in parallel." Does this sound better? Commented Jun 5, 2015 at 12:46
  • no, i don't know that my method is faster than abbreviated TLS. i did not know of abbreviated TLS. i do know about weaknesses of a shared key. this is why i am asking. i hope OPENSSL can do it. yes, pre-initializing a few streams ahead of time is a good idea, then as stream 2 goes into use stream 18 can start a handshake, for example.
    – Skaperen
    Commented Jun 6, 2015 at 9:43
  • it turns out i cannot use TLS to begin with ... my new question is: security.stackexchange.com/questions/91182/security-without-tls
    – Skaperen
    Commented Jun 9, 2015 at 11:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .