Schneier's post quotes the original article and says unfortunately we don't know more. Literally over 50% of it is a quote from another article which he derides for it's lack of substance. Not sure what the point is.
We all need to resist the urge to judge pages linked from HN in the context of "worthy of the front page of Hacker News". Sometimes authors are writing explicitly to that kind of audience, but often, as in this case, they're not. In the context of the service Schneier is trying to provide, this is a solid and useful post.
I also find supercomputers relevant to PRNGs, both on the overall PRNG security front and on the inadequate seeding front. Since CSPRNGs are not designed to be slow to calculate, supercomputers can be used to attack key generation from inadequate seeding, given some useful model of what the effective space of seeds could have been.
For instance, there are probably still many embedded systems that are initializing without anything that is reasonably called "environmental noise", and their state space is dangerously small, yet maybe still challenging for most organizations to search, depending on exactly what they initialized it with.
Of course (not that you disagree), if you have this problem, you have it with or without NSA supercomputers!
I don't think CryptGenRandom or urandom on general-purpose computers is a viable target for this, though, regardless of how "fast" the CSPRNG is.
The goal of this is that if there is a cryptanalytic attack that gives brute force a 2⁴⁰ speedup and hence attackers build custom hardware to implement it, their hardware is still not effective against the other cipher and they have to do something different (maybe hard to characterize how difficult the different thing would be anticipated to be).
If you're paranoid about AES, use Chapoly (or just use Chapoly because it's in many ways more convenient to use than AES). Don't build elaborate cascades (all cascades qualify), and don't randomize S-boxes.
It is hard enough getting these systems right when you're playing exactly by the book. If you're designing a cryptosystem and you're not a professional cryptographer, the list of things you should be worried about getting wrong is very long and very scary.
Serious question. I know nothing about crypto, just assumed "more is better, but slower".
AES-Serpent is probably not less safe than AES; it's just not necessarily as much more safe as you'd expect.
A much bigger concern than which precise ciphers you're using is which block cipher mode you're operating under; Truecrypt/Veracrypt uses XTS --- like most disk encryption --- which (among other things) isn't authenticated.
The funniest thing about TC/VC's cascades is that the keys are derived from passwords anyways: a giant clunking complicated block cipher cascade resting on top of a low-entry password secret. It's just a silly design.
AES-128 is the norm. No NSA supercomputer should convince you to use AES-256.
I can't tell if it's sarcasm. (it's a serious question)
When I was reading the news article, I thought to myself, should they really be publishing classified information? The dumb leak was one thing, but publishing it more broadly is a whole different thing. If this was a government contract, I would assume these are classified documents (which they are). Obviously we tax payers should have the right to know, but logically, wouldn't that consider a crime just like leaking to Wiki Leaks?
are you not familiar with the intercept? it was initally created mainly to publish snowden documents
> wouldn't that consider a crime just like leaking to Wiki Leaks?
we have freedom of the press in america
In the US, you effectively can, assuming you are actually the press and have the means of defending yourself. While there are laws on the books that supposedly limit this in various ways, they are generally not invoked - notice the government typically asks papers to delay publishing classified information they may have received.