Differences between NewHope-CPA-KEM and NewHope-CCA-KEM According to the web page for NewHope, an R-LWE post-quantum key encapsulation mechanism (KEM) candidate for standardization, it comes in types that are IND-CPA or IND-CCA secure. I know what CPA and CCA security are, but I don't understand the difference between the two types of NewHope and why there needs to be a choice between one or the other (unlike, say, RSA-OAEP which provides both).
Well, it turns out that a straight-forward implementation of LWE key exchanges is vulnerable to chosen ciphertext attacks, in the case that one side reuses the same private value $a$ multiple times.

In this straight-forward implementation, Alice generates a private vector $a$, and sends his key share $a M + \epsilon$.  Then, when Bob receives this key share, he generates a private vector $b$ and sends his key share $b M + \epsilon'$ and a reconciliation vector.  This reconciliation vector is needed because the vectors that both sides compute won't be precisely the same (because of the error vectors $\epsilon, \epsilon'$), and advise Alice how to do the rounding.

The best known attack involves the attacker sending incorrect bits in the reconciliation vector, which (over a number of exchanges) can yield individual values from the $a$ vector.

In the CPA version, they assume that you'll never reuse the same public value over multiple exchanges, and so this attack is irrelevant.

In the CCA version, they can't make this assumption.  What NewHope team has decided to do is to use to have Bob generate his key share from a seed in a deterministic way and encrypt that seed as a part of the ciphertext, and so when Alice gets it, she can decrypt the seed and then regenerate what Bob's key share should be (based on the seed), and see if that's the value she got; this prevents attacks (like the above) which are based on sending illegitimate keyshares.

Of course, all this extra checking slows things down; that's why the CCA version is slower.