3 ms·

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."