this crossed my radar in 2016 during a quantum networking retreat at Torry Pines. Talking with some crypto people in 2017, these notes kicked off adding a new algorithm for my test universe. ---
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3040224 https://arxiv.org/pdf/1509.02533 ieeexplore.ieee.org/iel7/6475439/6483185/06483432.pdf https://www.semanticscholar.org/paper/Media-Landscape-in-Twitter-A-World-of-New-Conventi-An-Cha/12dec1541d7e1528d5cc5ca5216c7c2f787387db https://www.cl.cam.ac.uk/~jgd1000/metaphors.pdf courses.csail.mit.edu/18.337/2015/docs/50YearsDataScience.pdf https://www.gov.uk/government/publications/the-exchange-and-protection-of-personal-data-a-future-partnership-paper https://royalsociety.org/~/media/policy/projects/data-governance/data-management-governance.pdf https://royalsociety.org/~/media/policy/projects/machine-learning/publications/machine-learning-report.pdf .. The security arms race continues…. Aging Crypto is begining to show Kracks Many years back, the observation was made that we (the industry) could monetize security by sprinkling “security pixie dust” on everything which would put security everywhere. Shortly after that observation was made, sane people admonished against the practice of putting security everywhere. But the money won and today there is a security option at every point in a communications path. A recent, high profile event was the introduction of KRACK (1), which shows the vulnerabilities in WPA2, a wireless link-level protocol that is used in all modern “protected” WiFi networks & systems. The ostensible problem is not the vulnerability itself, but that the protocol is widely deployed and embedded in nearly all WiFi gear made in the last 15 years. To fix the problem, one has to upgrade BOTH ends to a system that has not been hacked. Or decide that link-level encryption is not a generic panacea for security. This is but one recent example of a history of successful attacks on cryptography that has found its way into the systems we use and depend on daily. And here in lays a serious problem. Our lives are infused with pervasive cryptography that is broken outright or has serious, known wealness. Not only us, but those that govern us are affected in the same ways. This week in Washington DC, at the Cyberweek conference, one of the items being discussed was when does all our crypto break in a trivial fashion. It seems that most folks had thought that changing the key size will give us some breathing room but after this past weeks discussions, it is not so clear that we have time. (2) A takeaway was; “When quantum computing comes of age, even the most secure encryption on the planet likely will be shattered.” By some estimates, we have already past that threshold, others give us 60 months or so. Still, a very short time indeed. Why are we not better prepared? Well NIST has been thinking about the problem. They even held a workshop on the topic in 2015 and a request for proposals due next month. (3) There are plans to start a standardization process next year. But if all our existing systems are vulnerable, what options are there? I’ve asked a few security aware friends and other than submissions to NIST (or similar work), it seems we are going to be stuck with some varient of the McEliece Cryptosystem (4) (1978). And for the protocol folks out there, this is going to be HUGE. :) Heads up folks. 1) https://www.krackattacks.com/ 2) https://www.fedscoop.com/quantum-computing-coming-encryption-matter/ 3) https://csrc.nist.gov/projects/post-quantum-cryptography 4) www.math.unl.edu/~s-jeverso2/McElieceProject.pdf ----------------------------------------------------------------------------------------------------- On Tue, Oct 15, 2019 at 2:26 PM John Levine <jo...@taugh.com> wrote: > In article <2bcc20b2-9de0-a808-4e2c-054ff48f3...@icann.org> you write: > >On 10/15/19 12:11 PM, John R Levine wrote: > >> I just heard a most interesting talk at M3AAWG about postquantum crypto > and particularly about the NIST candidate > >algorithms. Many of them have much larger key or signature sizes than > any current algorithm, like 10,000 bits or > >more. Some are a lot slower than others. Has anyone been looking at how > these algorithms would or would not work > >with DNSSEC? > > > >Yes. (More specifically: > https://datatracker.ietf.org/doc/draft-hoffman-c2pq/, which is very > casually being worked > >on in the CFRG.) > > > >Or, define "work with". Falling back to TCP for getting DNSKEY records > might not be a big deal. > > Depends. A 1K key is one thing, a 50K key is another. If you are > rotating keys so you have multiple key records, and the keys are large > enough, what happens when the result packet is bigger than 64K? > > >Or, maybe wait until NIST has gotten more through the process, given that > key size and signature size are among the > >many factors they are considering. > > > >> NIST is accepting comments and the talk said they particularly want > comments from industry on how this would > >affect existing applications. > > The talk was by Brian LaMacchia, who opined it would e useful to send > in some comments about how various increases in key size, signature > size, and signing or verification speed would be likely to work with > DNSSEC. It sounds like they're paying a lot of attention to TLS in > their algo evaluations, a lot less to DNSSEC or DKIM or other > protocols. > > I'll see if I can get his slide on the key and signature sizes for the > candidate algorithms to be roughly as strong as a 3K RSA key. One of > them would need a 500,000 bit key which makes me wonder what they were > thinking. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
