Hacker News Reader

If I can expand on my own comment briefly, the thing I'd want to point out about that bulleted list is that they aren't new things you can apply interesting crypto things to, but modern constructions that address universal problems.

XEX and XTS, for instance, are used for disk encryption; disk encryption isn't a new problem, but it was poorly addressed by 1995 constructions, in ways that could create security-crippling tradeoffs.

> RSA (and Rabin) and conventional DH, both of which are looking increasingly sketchy in 2013.

May I ask why you say this? (Not agreeing nor disagreeing, just curious.)

Elliptic curve cryptography isn't vulnerable to quantum computing. EDIT: This is mistaken. I was thinking of lattice-based cryptography, which isn't currently vulnerable to quantum computing.

In the video game Final Fantasy, there's a spell called "Doom" which places a countdown over your head. When it reaches 0, you die.

RSA is Doomed in exactly that sense: it's just a matter of time before RSA offers zero security, whereas elliptic curve cryptography remains (for now) unbroken.

It is [1]. Quantum computers, using Shor's algorithm, polynomially break any specialization of the abelian hidden subgroup problem; see [2] for a fairly complete list.

Whatever reason to prefer elliptic curves over integer factorization or discrete log-based schemes must be classical.

[1] http://arxiv.org/abs/quantph/0301141

[2] http://pqcrypto.org/quantum.html

Oh.

Then which (if any) algorithm is currently believed to be safe from quantum computing?

I think I was thinking of lattice-based cryptography.

There's a bunch of them. There's no known quantum algorithm for quickly decoding binary linear codes, so McEliece is one. The Clostest Vector Problem in linear algebra is another trapdoor that may be QC-resistent.

You didn't ask, but it's worth saying: block ciphers, stream ciphers and hash functions aren't thought to be fundamentally threatened by QC the way IFP and DLP number theoretic cryptosystems are.

"it's just a matter of time before RSA offers zero security"

This is not the only possible outcome. Scalable quantum computing could turn out to be impractical due to cost. Or new physics could be found that rules out scalable quantum computing. Personally, I find both of these outcomes unlikely, the second more than the first, but they do exist.

It's easy-ish to move from RSA to ECC schemes, because they have significantly smaller key sizes and gain efficiency. The same isn't true of lattice schemes, which have significantly larger keys.

A switch to lattice or code-based crypto seems unlikely in the near future.

Daniel Bernstein has been talking about advances in IFP, particularly the batch numeric field sieve, for several years now; the question seems to be when, not if, 1024 bit RSA keys will be arbitrarily attackable.

Meanwhile, over the past couple of months, there's been a flurry of activity on the DLP, particularly Antoine Joux' work on the index calculus approach. The IFP and DLP are intertwined problems, but RSA also depends on the hardness of the DLP, as does (obviously) DH and ElG.

The advances we're currently seeing do not appear to threaten the elliptic curve discrete log problem.

Quantum computing is an issue, but it looks like a far-off issue. The record for quantum factorization right now is 27, right? If you believe QC is a near-term threat, no mainstream number-theoretic (public key / key agreement) cryptosystem helps you; you need to be working with code-based or lattice-based crypto; nothing does this now.

The problems motivating the shift from RSA to ECC are near-term, not far-off like QC.

Shit, I didn't look who I was responding to. Ignore the tone; assume I'm addressing the thread, not you.

No problem. Agree that quantum is not really something to worry about, though it's a good thing that someone out there is thinking of alternatives.

By the way, the Batch NFS has seemingly fallen out of favor. Despite being significantly faster in the usual RAM computational model, it has worse AT complexity than factoring integers one by one (see section 5 of [1]), due to its crazy storage requirements. It doesn't change the fact, of course, that RSA-1024 doesn't have much shelf life left.

[1] http://eprint.iacr.org/2012/318

I agree that I wouldn't treat the HAC as a "discovery" reference, for lack of a better term. Like you point out, there are modern-day concerns and constructions that are omitted. But I argue that if you are designing a protocol or choosing a primitive, you shouldn't have to consult a book to figure out which encryption mode to use or how to use a MAC. If you do, then you probably aren't qualified to be designing a protocol in the first place!

The HAC really excels as a specific, targeted reference for a cryptography-aware audience. For instance, if you're wanting a good, standard notation for something, the HAC is a great place to look. Or maybe you'd like to give a specific definition in a paper. (For instance, what is a precise definition of a MAC?) Then the HAC is a great place to look.

So, I agree that a designer shouldn't use the HAC as a sole reference, especially if they're unfamiliar with cryptography. This goes doubly so if what you're trying to do is estimate the security of a construction. But really, to know much about the cryptographic security of a scheme or construction, you really need to be up-to-date with the current research, not just looking at books. A book is a good first pass filter, if you will, but if you're judging security, you really want more.

> a designer could be forgiven for reading Menezes and not including explicit integrity checks at all.

Section 9.6.5 goes to great lengths to ensure the reader is fully aware that encryption doesn't provide integrity. Also, Menezes does present (an albeit brief) note on encrypt-then-MAC. I don't see the HAC as a teaching text, though. Anyway, I doubt there are many people who have "read" the HAC. It's a pretty thick book.

> It's not true that robust cryptography appreciates maturity. The ~twenty years since Menezes wrote HOAC haven't just been spent inventing whizz-bang new toys, but also in finding new ways to break the old toys. You're not always OK if you eschew the new stuff for the "mature" stuff; some of the mature tools are perilous to work with now.

I think robust cryptography absolutely appreciates maturity. But don't mistake me saying that for me saying that maturity is the only desired trait: far from it. scrypt was not recommended as highly as bcrypt for a few years after its release, and still one of the major selling points of bcrypt is "it's been around a while." And let's not forget the four-year period that the SHA3 competition spanned. Some minimum amount of maturity is required of all schemes that are considered secure.

So, maturity isn't a decision-making factor, no. But a construction that's been around for a long while and has seen virtually no attacks (but is widely studied) is essentially the gold standard. See AES. On the other hand, I think you'd have a hard time arguing that a relatively new construction that's seen virtually no attacks isn't less impressive, even if it has some improvements over an older scheme.

But again, I agree entirely that "mature" isn't always better. But it's definitely a factor, although whether it's a large or small factor mostly depends on the circumstances.

> what parts they need to hold off on, like homomorphic encryption

If you mean fully homomorphic encryption, then sure. However, we already have practical partially homomorphic schemes which are pretty good. But this area especially requires a cryptographer's assistance in design, even moreso than a typical "confidentiality/integrity" application.

---

Anyway, I guess ultimately, if you're just looking for a good text that's useful in learning cryptography, the HAC isn't the first place I'd look. But if you'd like an encyclopedic reference, it does a great job (IMO). If you're looking to build up a cryptography reference, though, it definitely needs to be supplemented with many other texts.

Edit: Also, another thing I find myself using the HAC for is to get a certain sort of historical context (regarding attacks and constructions) in an area before moving on to more advanced, more modern texts. Those more modern texts tend to leave out such details for brevity's sake, but I like knowing them all the same.