Wednesday, October 09, 2019

0.0 Introduction

I just posted this introduction to the project here.  I hope you'll follow along as I fill in the postings.

There are two fundamental reasons for periodic rekeying:
  1. Having a long string of data encrypted with the same key increases the ability of an attacker to find the key.
  2. As a practical matter, reducing the amount of data that is exposed in the event that a key is broken is good stewardship of your data.
So changing the key "often" makes it both harder and less valuable for an attacker to find a key.  That's the tl;dr.  Turning it into concrete, numeric recommendations is hard, but it looks like rekeying every half hour is pretty good, if your key bandwidth isn't high enough to do full one-time pad.

The above I knew off the top of my head, but I'm not a cryptographer and had more or less taken the need for changing the keys (known as rekeying) on faith.  So, let's dig a little deeper...there won't be any new knowledge in this, but I hope it helps bring together some information and organizes it to both save you the googling and calculating I've done and to provide a clear picture.

I used to work on a box known as an IPsec gateway, but I was the OS guy, not the cryptographer; Darrell Piper, Dan Harkins and Dave Kashtan did most of the crypto work.  I am also a board member of the WIDE Project, which through its KAME Project created the Racoon software that was an important early implementation of the key exchange protocol for IPsec, with much of that work done by Shoichi Sakane.  Much of what I know about IPsec and other security was just incidental radiation from them, or gained from the security-oriented papers we had to read when I did my master's at USC back before the Enlightenment.

I'm afraid this has gotten longer than I originally intended, so I hope it's all useful.  It's so long, a table of contents is in order:
  1. Brief, mostly non-mathematical intro to cryptography and its terminology, in the context of encrypted communications.
  2. General ideas behind cryptanalysis and the importance of limiting data volume, since that's the topic that started this conversation.
  3. How these ideas play out in IPsec, one of the Internet's key security protocols.
  4. How these ideas play out in TLS/SSL.
  5. Quantum and crypto.
  6. Post-quantum crypto.
  7. ACT NOW and order the above package, and as a FREE bonus, Ronco (well, Rodco) will send you a few thoughts on Bitcoin and its vulnerability to the development of quantum computers!
  8. References
Next posting is here.

No comments: