4 ms·

Amazing project. And I love the understated tone of this in the README: "Security Requirements: The user is responsible for ensuring that any individual connec

Amazing project. And I love the understated tone of this in the README: "Security Requirements: The user is responsible for ensuring that any individual connection does not transmit more than 2^64 bytes." If you don't happen to know how big 2^64 bytes is, it's over 18 BILLION GIGABYTES! We can probably safely assume most of us will never hit that limit on a single connection, haha. Ref: https://code.google.com/p/spiped/source/browse/trunk/README https://code.google.com/p/spiped/source/browse/trunk/README

cperciva 13y ago
You also have to ensure that you don't create more than 2^64 connections using the same key.
- mattjaynes 13y ago
  omg, I love you. Yes folks, also, remember not to create 18 QUINTILLION connections (18 billion billion) with the same key. :)
  - mattjaynes 13y ago
    Apparently my comment is being misinterpreted (evident by the downvotes) :/ To clarify: It's simply amazing the scale at which you have to get to for spiped to need a new key. It's a tribute to its design and its author. If I understand it right, in order for this to be a real issue, an attacker would have to spend decades or centuries diligently recording either 18 quintillion connections or 18 billion gigabytes of your encrypted traffic in order to even begin to try cracking the key in any serious way. The solution to this "vulnerability"? Switch out your key (takes a few seconds tops). I laugh because of Colin's dry humor matter-of-factness about this mind-blowing level of scale. If you missed his own poking fun at it, read his other comments in this thread :)
- tokenizerrr 13y ago
  Do you have any recommendations on how to manage this? I realize this number is quite huge, and likely will never become an issue for me, but I'm not sure how I would manage or monitor the amount of connections a third party application creates.
  - cperciva 13y ago
    Don't try to count, just establish an upper bound. "I have 1000 servers using this shared key, and they each open at most 1000000 connections per second, so as long as I change the key in the next 500 years I should be fine."
nknighthb 13y ago
An interesting assumption to consider. Just to pick one current example, JUS[0] presently has a capacity of 1.28 terabits per second. If, for some reason, we were to run it at an even 1tbps, piping all data through a single spiped connection, the security requirement would be broken after just over 4.25 years of continuous operation. 8 streams of uncompressed 4320p@60fps video multiplexed into a single spiped connection would also break that requirement in a bit over twice as much time. These are contrived but possible scenarios with present commercial technology. In 10-20 years, that assumption might not be so safe. [0] http://en.wikipedia.org/wiki/Japan-US_(cable_system) http://en.wikipedia.org/wiki/Japan-US_(cable_system)
drdaeman 13y ago
2050s had called and asked for spiped to have a default behavior to terminate the connection in such cases, so accidental disclosure would be prevented no matter what.
- tinco 13y ago
  I hope you mean the 2020s. It's optimistic to think we would still be allowed to run custom software in the 2050s, and pessimistic that we wouldn't have multi-terabit connections before 2050.
  - al2o3cr 13y ago
    Oh, you'll have a terabit connection in 2050 - but the D/L cap will still be 50 GB. :)

cperciva 13y ago

You also have to ensure that you don't create more than 2^64 connections using the same key.

mattjaynes 13y ago
omg, I love you. Yes folks, also, remember not to create 18 QUINTILLION connections (18 billion billion) with the same key. :)
- mattjaynes 13y ago
  Apparently my comment is being misinterpreted (evident by the downvotes) :/ To clarify: It's simply amazing the scale at which you have to get to for spiped to need a new key. It's a tribute to its design and its author. If I understand it right, in order for this to be a real issue, an attacker would have to spend decades or centuries diligently recording either 18 quintillion connections or 18 billion gigabytes of your encrypted traffic in order to even begin to try cracking the key in any serious way. The solution to this "vulnerability"? Switch out your key (takes a few seconds tops). I laugh because of Colin's dry humor matter-of-factness about this mind-blowing level of scale. If you missed his own poking fun at it, read his other comments in this thread :)
tokenizerrr 13y ago
Do you have any recommendations on how to manage this? I realize this number is quite huge, and likely will never become an issue for me, but I'm not sure how I would manage or monitor the amount of connections a third party application creates.
- cperciva 13y ago
  Don't try to count, just establish an upper bound. "I have 1000 servers using this shared key, and they each open at most 1000000 connections per second, so as long as I change the key in the next 500 years I should be fine."

nknighthb 13y ago

An interesting assumption to consider. Just to pick one current example, JUS[0] presently has a capacity of 1.28 terabits per second. If, for some reason, we were to run it at an even 1tbps, piping all data through a single spiped connection, the security requirement would be broken after just over 4.25 years of continuous operation. 8 streams of uncompressed 4320p@60fps video multiplexed into a single spiped connection would also break that requirement in a bit over twice as much time. These are contrived but possible scenarios with present commercial technology. In 10-20 years, that assumption might not be so safe. [0] http://en.wikipedia.org/wiki/Japan-US_(cable_system) http://en.wikipedia.org/wiki/Japan-US_(cable_system)

drdaeman 13y ago

2050s had called and asked for spiped to have a default behavior to terminate the connection in such cases, so accidental disclosure would be prevented no matter what.

tinco 13y ago
I hope you mean the 2020s. It's optimistic to think we would still be allowed to run custom software in the 2050s, and pessimistic that we wouldn't have multi-terabit connections before 2050.
- al2o3cr 13y ago
  Oh, you'll have a terabit connection in 2050 - but the D/L cap will still be 50 GB. :)