Slashdot Mirror

you need root privileges to bind to port 80

Common sense would indicate that in that scenario you either

• 1. Get the socket as early as possible in startup then setuid(2) yourself to a user with lower privileges (and chroot yourself, while you are at it) before answering any requests
• 2. Failing that, run on a high numbered port and have iptables forward you traffic from 80, which is a specific instance of the more general strategy: run as little code as possible at high privilege

What's not an answer is "run the actual process as root while serving user requests". It's shocking that this is even considered remotely like a possible solution.

What's doubly galling is that there is a loooong unix history of applications that require far more intrusive privileges using both or these techniques -- either getting what they need and immediately dropping to the position of least privilege or using a small shim or utility that runs in a high-privileged space and communicates with the rest of the service via IPC. So it's not like they couldn't draw on those examples or literally just copy-pasta DJB's code.

What's triply galling is that the fix doesn't actually appear to mentioned fixing any of this, just patching this one vulnerability.

They may have aligned with findings from Safecurve project.

But legally you can't implicitly abandon your copyright.

The FUD continues. I refer you to D. J. Bernstein's page on the subject of waiving copyright.

And regarding your analogy, you're talking about an implied easement based on prior-use. Your example lacks a lot of pertinent detail, but to answer your question, depending on the particular circumstances, it's possible that you would not have a legal right to put up that fence (see example).

HTTPS itself is fine, but some of the algorithms it can use are questionable. In particular, the NIST p curves (which are the most widely supported curves used for elliptic curve cryptography) are mega suspicious -- the method for picking them was to have an NSA employee tell NIST "here are the curves you're going to use". Also, the justification for those curves was their performance, yet they aren't actually very fast, _and_ they have certain characteristics that make it easy to screw up your implementation. One wonders why the NSA wanted these particular curves to be standardized rather than a different set.

There is now the much better choice of Curve25519, but it has only recently gained support in TLS libraries and browsers.

(If you want more detail on the issues with NIST's p curves, see this talk, and if you're wondering whether the NSA would really try to undermine a public standard, see the Dual EC random number generator.)

I am betting that NTRU Prime will likely be the post-quantum asymmetric winner of the NIST competition.

...at least, according to DJB.

To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2 ^ 521 - 1; but the sheer size of this prime makes it much slower than NIST P-256.

I do understand, however, that it is difficult to produce an implementation of any of the NIST curves that are invulnerable to side-channel exploits.

What weakness in ECDSA?

Let's ask a better expert.

That's because U2F is a one-way authentication standard. It authenticates you to the service.

U2F is a wrapper around OpenPGP in one direction. It could have easily been a wrapper around OpenPGP in its entire, but it's not.

Yubi's more expensive/featureful devices add a built-in OpenPGP Smartcard [wikipedia.org] -- which is an entirely different standard.

They don't provide an open standard to implement OpenPGP to these devices through the browser, across generic carriers (USB, NFC, BTLE, etc.), and so forth. They don't say, "When you build a device to do this, build it to talk this way".

U2F and UAF have caught on pretty well across several services. They've got browser integration in Chrome. We didn't get integration in e-mail clients, phone SMS apps, and the like to encrypt and thus make secret your conversations in a nice, user-friendly manner--which would have happened if it were in the standard.

That irritates me. The damned things are capable, the protocol specification is capable, and they didn't take advantage of the opportunity.

Safely implementing crypto in java is a nightmare, thanks to the JVM. Java also doesn't provide modern algorithms like Curve25519 for key exchange or ChaCha20-Poly1305 authenticated encryption, both of which are very fast and secure even in software, and designed to avoid common pitfalls in implementation. RSA is slow with stupid-huge keys, and the NIST ECC curves are not safe, slow, difficult to implement correctly, and possibly compromised by the NSA. Ed25519 is also available in libsodium and available for golang, if not present in the standard library.

Libsodium is an extended fork of Daniel J. Bernstein's original NaCl project (not to be confused with Google Native Client), which is a cryptography library developed with the overarching aim of simplifying (and improving the implementation-level safety of) the practical use of strong cryptographic constructs. The "big idea" behind NaCl was to abstract away many of the low-level choices and technical details associated with various cryptographic primitives in favor of more "generic" interfaces, utilizing implementations of algorithms that are widely deemed strong and safe behind the scenes. Thus, the potential for human error via misuse or misunderstanding of various primitives would ideally be reduced, and overall security posture could be improved for many applications, without every developer needing to spend years becoming a cryptography expert. For additional background on NaCl, you might reference the following paper: The security impact of a new cryptographic library. Like its predecessor, libsodium is freely licensed, and developers are encouraged to embed and distribute the library along with their projects.

Hope this helps. -PCP

Libsodium is an extended fork of Daniel J. Bernstein's original NaCl project (not to be confused with Google Native Client), which is a cryptography library developed with the overarching aim of simplifying (and improving the implementation-level safety of) the practical use of strong cryptographic constructs. The "big idea" behind NaCl was to abstract away many of the low-level choices and technical details associated with various cryptographic primitives in favor of more "generic" interfaces, utilizing implementations of algorithms that are widely deemed strong and safe behind the scenes. Thus, the potential for human error via misuse or misunderstanding of various primitives would ideally be reduced, and overall security posture could be improved for many applications, without every developer needing to spend years becoming a cryptography expert. For additional background on NaCl, you might reference the following paper: The security impact of a new cryptographic library. Like its predecessor, libsodium is freely licensed, and developers are encouraged to embed and distribute the library along with their projects.

Hope this helps. -PCP

Looks like it's faster in hardware currently which makes sense for credit-cards and other low power systems. Judging from the benchmarks done it looks like Skein was the fastest however (but this of course benched with software and not hardware). https://bench.cr.yp.to/results...

Because DJB, aka Dan J. Bernstein, screwed up the licensing on daemontools.

There was very similar init structure that worked quite well, at https://cr.yp.to/daemontools/. Dan's tools, like his work with djbdns and qmail, was quite robust and appreciated by many developers willing to build their own versions from source. They also worked quite well on all the UNIX systems. However, Dan invented his own "special" licensing, one where you were not allowed to publish binaries with any patches applied. If you wanted to include patches, such as for example taking this tools out of the top of the file system where they did *not* belong, you had to publish his source and patches for others to apply.

No one, not Red Hat, Fedora, Debian, Gentoo, nor any of the UNIX distributions, could work with this nutty licensing. So *no one* could use it by default nor devote production time to it for operating system releases, so it languished. Eventually Dan gave up and made it completely public domain, but the damage was done. Systemd gained popularity in the meantime.

Just to be more linguistically clear in terms of validation, you validate the user supplied secret against a properly formed (that's important) stored salted hash stored server-side via a separate algorithmic construct. You never perform a straight bit-wise comparison of any such values (regardless of any intermediary hashing or other transformative operations that may have been performed at any earlier stage). On a tangential note, highly effective cryptographic attacks, remotely and locally executable alike, have been derived from implementation flaws as simple as failing to perform string primitive comparisons and other basic operations in constant time. -PCP

Nope. For one of my sites, I have three CSS files; all the others only have two CSS files: One for really narrow screens, and another one for the full sized site.

HTML has always been designed to adapt to different screen sizes; sure, the text flow will be a little different for a slightly narrower or wider screen, but the site remains readable and usable. Indeed, a good 1990s web design which uses HTML only for markup is perfectly usable on a modern small-screen smartphone.

Not only that but the submissions during the AES process came from all over the world. And looking at the names of the current submissions to the upcoming CEASAR I wonder if there is even a single American among them: https://competitions.cr.yp.to/...

Believe it. I've done it, and I was nowhere near the first. You might find some of D.J. Bernstein's work interesting. -PCP

It would seem you haven't spent any time on cr.yp.to. If you're interested in topics related to information security, I recommend it. -PCP

http://www.dshield.org/diary/W...
http://tech.slashdot.org/story...
http://cr.yp.to/djbdns/forgery...
http://it.slashdot.org/story/1...
http://www.dshield.org/diary/R...
http://www.microsoft.com/techn...
http://www.microsoft.com/techn...
https://www.us-cert.gov/ncas/a...
http://www.theregister.co.uk/2...
http://www.dshield.org/diary/D...
http://www.dshield.org/diary/N...
http://www.dshield.org/diary/U...
http://www.dshield.org/diary/M...
http://www.dshield.org/diary/D...
http://tech.slashdot.org/story...
http://www.theregister.co.uk/2...

APK

P.S.=> Next is GLibC faults, DNSAPI.DLL alteration attack, FastFlux/DynDNS attacks, DNS misconfiguration, DNS DDoS attacks, DNS amp attacks, DNSSEC fails, OpenDNS resolver problems, DNS IP spoofing, Ghost Domains due to DNS, router DNS issues, Rogue DNS servers abused, DNS serving up malware + SO MUCH MORE it will finish your DNS BS w/ ease - then it's onto Antivirus!

Yes. We know. In the end, the complexity of the attack and the circumstances required are so specific that it simply isn't a viable attack vector.

This *peculiar* form of the attack is complicated: paying attention on the charging port. Possible implementation are quite limited (basically, having a public charging station with hacked USB charging ports).

BUT, the same kind of attack vector (listening on outside signals to try to guess what's happening inside the computer) has had in the past a few quite more usable forms: a group of security researcher has presented guessing the key based on the *noise* produced by the computer. Works even with a smartphone's mic.

And that's much more easy to put into practice.

In other words, yes, you can die from a lightning strike. But that doesn't keep you inside, does it?

It doesn't keep you inside, but it asks for minimal caution: you won't be waving a long metal rod, while completely wet and standing on the top of a high hill during a big thunder storm either.

Or to go back to TFA: this won't necesserily stop you from using online payment, but would maybe prompt the OS and hardware manufacturer of smartphones not to use implementation of the crypto algorithms that have data-dependent bahaviour (conditional jumps, memory data manipulation or memory allocation that are dependant on the clear-text data or the key data). From the outside (and that means even to the eyes of another process running on the same CPU), the smartphone should behave the same no matter what sensitive data it is handling. Even if such implementation are slightly less efficient and slower thant the data-dependent variations (that's the case with AES, for example).

  There are such exemples, see Daniel J Bernstein's NaCl library

but smartphone makers could thwart all attack of this type by ensuring current draw while charging is consistent as to make it impossible to determine what the phone is doing.

Or simply use implementation of ECDSA, AES or other primitives that are note data-dependent (which behave always the same, no matter what plain-text or what key is submitted to them).
example of a library build around such principles by Daniel J Bernstein.

If an implementation makes some jumps or some allocations or some data manipulation, these are points that can be eavesdropped on.
If an implementation does always the exact same step no matter what the data is, you'll have a lot less to spy on.

The problem is that newer is not necessarily better. I don't trust NIST much at the moment thanks to the NSA plants in it, nor do I trust anything with the words "elliptic curve" in it (especially any with "magic" constants).
The old algorithms like RSA and DH are simple in concept, and have withstood the test of time algorithmically. Sure key lengths had to get longer due to Moore's law and some computational improvements, but no serious attacks are exist against them. It's unwise to ditch these methods any sooner than we have to.

I'm afraid in asymmetric signatures and Diffie Hellman, newer certainly is better.

The security of RSA is steadily being chipped away by improvements in index calculus. That is why RSA keys need to be so much longer than ECC keys.

The issue of magic constants is termed 'rigidity' by crypto nerds. I.E. Did the algorithm designer get to choose being multiple possible versions? Or did they have to follow a defined procedure to get to the values in the spec. Rigidity is one of the safecurves criteria and the only sane thing to do with elliptic curves is go with the safecurve compliant algorithms.

Five years ago I was arguing strongly (and successfully) against the adoption of ECC in certain standards because there were a number of uncertainties. Events have since shown that be correct. The death of binary fields, the NIST curve constants, the twist insecurity of P-224, etc. Now the tables have turned between RSA and ECC. We have a much better understanding of the security of ECC and how to build good ECC curves. We know NIST curves are untrustworthy. We know the sidechannel properties of hardware implementations of group multiplication over different prime group orders over ECC curves. RSA is getting weaker steadily, mostly through better cryptanalysis and sidechannel issues. If you're deployment RSA-2048 in a product that has to last 20 years, you're making a big gamble. If you deploy RSA-1024, you're not taking the problem seriously.

The LogJam attack that was doing the rounds yesterday highlighted the folly of doing Diffie Hellman in prime fields, rather than elliptic curves. The paper didn't adequately address the issue that fixing a prime in a spec is something you really want to do for a number of reasons but they got the recommendations right - move to ECC. Moore's law caught up with the practice (of fixing primes for prime fields over which to the DH) . Don't make the mistake of inventing complex prime negotiation protocols. Move to ECC.

This is completely wrong. Modern cryptographically secure PRNGs can generate practically unpredictable sequences of as many numbers you'd like from an initial seed of >= 256 bits of entropy. This is actually how modern cryptography works in general: you wouldn't expect a 256-bit AES key to suddenly become insecure and predictable after encrypting a certain amount of data, would you? Why would a CSPRNG be any different?

In fact, both /dev/random and /dev/urandom are CSPRNGs. /dev/random is *not* a true RNG. It's just a CSPRNG that tries to reseed constantly and blocks when it can't based on an /estimate/ of the available entropy, but this constant reseeding is unnecessary for the same reason that we don't have to cycle AES keys constantly. It may make things harder for some contrived threat model when the attacker is able to glean your PRNG state periodically, but the practicality of this model is doubtful. djb has a very good article on this.

secure key-stream, like is done in modern stream ciphers.

RC4 biases paper (PDF) would like to hear more about your secure key streams...

Yes, XOR can be used as a component of perfectly secure cipher (and is, indeed, used in one part or another of many real-world ciphers) but in practice the most popular stream cipher in the world is broken.

RC4 was designed in 1987. It's several years older than Linux and Taylor Swift. The poster clearly referred to modern stream ciphers, such as ChaCha20, and didn't mention popularity...

secure key-stream, like is done in modern stream ciphers.

RC4 biases paper (PDF) would like to hear more about your secure key streams...

Yes, XOR can be used as a component of perfectly secure cipher (and is, indeed, used in one part or another of many real-world ciphers) but in practice the most popular stream cipher in the world is broken.

Focusing on NIST and the NSA

Choose a safer curve

Unplug the network.

Seriously though, Daniel Bernstein has put a lot of thought into that question. You can start here.

Right? Since it's posted here I'm interested, yet suspicious of whether these are really good recommendations.

Yes. They are good recommendations.

For example, Curve 25519 is structured such that all the usual implementation problems can't happen. See safecurves for why.

MinimalT allows servers to require the solution of puzzles to defend against certain types of DoS attacks.

For brute force bandwidth flooding, we'll just need bigger pipes. Practically speaking, Cloudflare seems decent.

The headline is wrong. The ISP is removing the mail server's announcement that it supports STARTTLS, and your mail client/server sends your email unencrypted.
The solution to that is using SMTPS on 465, where encryption is presumed, not negotiated. But that was deprecated soon after the RFC came out in favor of TLS. It's almost like someone was thinking ahead and wanted the internet to be less secure:
http://cr.yp.to/talks/2014.10....

Somehow I expected that the Voynich manuscript would come up. It's not a very good argument though. We don't know if the contents of that thing are even supposed to make sense. You can't decrypt /dev/random. In general, where you have data, you have context. That context helps deciphering the data, unless care is taken to make that impossible. And with "care is taken" I mean "cryptography is applied". If you make up a new language, it probably won't be a cipher that is better than encoding that information in an efficient way and running it through a cryptographic cipher.

Well. You could encrypt something and then map that back into a grammar and speakable words, but that's cheating.

That is why I threw out book codes or one time pad codes as an example. They're unbreakable without the pad. As in NEVER.

You also ignored all the issues those have and which I mentioned.

Today's symmetric ciphers commonly have key lengths of 128bit or 256bit and usually there aren't even purely theoretical attacks that are significantly faster than brute-force. If you have a cipher with very conservative safety margins, such as ChaCha20, and a key length of 256bit that is pretty much unbreakable without the key too.

For comparison, the estimated total number of fundamental particles in the observable universe is somewhere in the range of 2^265 to 2^282. Maybe you would be satisfied 384bit keys? "2^100 times more states to check than there are particles in the universe" has a nice ring to it.

but that's just because that's the weakest link. You don't waste your time with the tough stuff if you can find something softer.

No, that's because modern cryptography is so strong that trying to break it is pretty much futile. If the cryptography was a viable target, it would be targeted, because then you could break all the implementations at once.

Added to what I said above, I think systems that are secure must be simple. Very simple. As in no more then a couple pages of code. Why? Because complicated code is code that can't be debugged. Keep it simple and you can make the code perfect. Total confidence that there is zero error. As in 1+1=2 perfect.

Simplicity is good, I agree. However, many actual cryptographic algorithms are rather compact. AES is just a few pages of code. So is ChaCha20.

As I said before. The cryptography is not the problem. Usually it's not even the code for the cryptography. Granted, there have been some cases of sidechannel attacks, but those can be (mostly) avoided with proper care.

A perfect OTP implementation won't help you if your application is leaking random memory blocks (including your OTP) to an attacker heartbleed-style.

The sort of thing you'd trust to keep out the literal devil.

The devil applies "simmer in a pot full of literal liquid hell fire" cryptanalysis, I believe. Apart from that, 256 bits of security should be enough against that guy.

IPv6 was not designed to allow for a graceful transition from v4. The feet-dragging is completely rational. http://cr.yp.to/djbdns/ipv6mes...

Precisely why some of us run critical services under Daemontools ... simple, clean, and reliable. Its logging concept is a vast improvement over syslog for local logging, and if you're not into it, it doesn't force you to use it at all.

You want to make sure SSH is always running or trying to run? Put it in a /service ... it will start or at least keep trying.

The trouble there is that the iMessage stuff is all based on key escrow by Apple (obvious results are obvious) but also troubing is keychain sync - look there on Page 24 - they're having the user sign it with ECC P256 which everybody knows is broken and an NSA setup.

This iOS security document is probably the best they can do to warn us, given a gag order. Given that the rest of the document proudly calls out P25519 usage (smart) and then the one-of-these-things-is-not-like-the-other-ones moment is the keychain sync, that seems to point to that being the target of the Bullrun operation at Apple.

If I were trying to be secure on iOS (hypothetically) I'd have turned off keychain sync by now.

Right - 25519 in particular is well-regarded. It may be that everybody in the field[sic] is wrong, but at this point it's considered stronger than RSA, and possibly resistant to quantum attacks which RSA is not.

Looking at risks today, it's more likely that OpenSSL's RSA code has vulnerabilities than curve 25519 has breaks. We are not just looking at algorithms here, but implementations.

If I were on OpenBSD I might feel comfortable using LibreSSL with guard pages, but for my linux-to-linux machines in a glibc world, I'd be willing to replace my RSA keys at this point for security-sensitive work.

Thank you, Team OpenSSH.

Yup, that is indeed what's missing inside something like openssl.
Throw in a secure compare in way that doesn't cause confusion (i.e.: avoid's openssl's CRYPTO_memcmp vs OPENSSL_memcmp. If you really need the later, call it something unambiguous like "leaky_memcmp"), and bound checked substring copy, and you have basically covered all needs of a crypto library.

That really isn't right, is it? You're abusing the notion of "backdoor." The evidence that a backdoor is possible is incontrovertible. But practically speaking to have access to that backdoor you have to develop the backdoor values as part of defining the curve for the standard / implementation. If you don't develop the backdoor values as part of defining the curve then you are essentially back to solving the original problem in order to get your "shortcut". In other words, it is no help at all if you don't do it from the start. An unknown "backdoor" that is as hard or harder to solve than the original math problem isn't really what you could call a backdoor in conventional terms, is it?

Conclusions about Dual_EC_DRBG

The bias in the output mentioned earlier is concerning, but there are no known attacks against Dual_EC_DRBG unless you have pre-existing knowledge of the relationship between P and Q. In other words, this backdoor (if true as alleged) allows the NSA to break Dual_EC_DRBG but does not make it much vulnerable to anyone else. This is much different than a backdoor password which would be immediately usable by any adversary who discovered it (e.g. by reverse engineering the code).

On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng

You seem to think that this is a theoretical argument. Please find one bug in the original DJB qmail code and then you will be worthy of taking this discussion further. The OpenBSD people have lead the way and shown that even starting with a messy entire operating system you can seriously move in the direction of secure, bug free code.

The point is that there is a choice; one which becomes very visible when you have a security vulnerability found. Do you fix that one single bug or do you pay a little more and go through your code base looking for every single one like it? Many proprietary vendors choose to do the one single minimal fix, which is wrong and is part of what is driving the visceral reaction to your post which reads, to some of us, like an excuse for them.

djb’s commentary on IPv6 remains valid today: http://cr.yp.to/djbdns/ipv6mes...

They did, you moron. Just like your post is moronic, but not every moronic post is yours, there is an elliptic curve designed by NIST, but NIST didn't invent (and backdoor) every elliptic curve out there.

"25519" in Ed25519 stands for elliptic curve named "curve25519" designed by D.J. Bernstein.

According to Dan Shumow and Niels Ferguson's 2007 presentation, finding the private key e corresponds to solving one instance of the elliptic curve discrete log problem, which is believed to be a very hard problem indeed, and probably not even doable for a any current supercomputer.

Boot up speed is incredible with /service (see http://cr.yp.to/daemontools.html) and dependencies aren't hard to wire into those scripts at all. What kills me is that systemd is so much more complex for no gain over something so simple as an auto-restarting shell script.

In crypto you don't have prove back doors exist, you show the algo is not fit for purpose. The NIST standards were not fit for purpose.

http://safecurves.cr.yp.to/

The NIST curves being insecure doesn't only apply to random number generation. SSL still uses NIST curves for almost all other ECC, which includes most of the perfect forward secrecy ciphers. If the NIST curves are really broken, SSL (as deployed) is also broken. (Try "openssl ecparam -list_curves" sometime. NIST curves dominate the landscape and they are most often chosen when using ECC.)

There's speculation that the curves were selected because they make ECC (ECDSA, ECDH, etc) weaker than would be expected. If so, this would be true even if a non EC RNG is used.

There really isn't any way of knowing. The possibility of a weakness with the elliptic curve cryptography is only suspected, suggested, not proven.

Wrong.

Weaknesses have already been academically shown. Both the fact that it's remarkably slow (for the quality of the produced pseudorandom bitstream) and the fact that it displays backdoor-like properties has been shown elsewhere. Contrast that with DES which, although there were suspicions that the design of its S-boxes might have had ulterior motives (which, again, is a FAIR assumption whenever the design guidelines of cryptographic primitives is not transparent), has never been actually proven to actually contain backdoor-like properties (unlike Dual_EC_DRBG).

And, well... I'm not even taking into account the Snowden leaks that strongly suggest that NSA has been subverting standards and coercing companies to weaken their cryptographic algorithms (like this one by Reuters).

Good 'ol Bruce has said that there is nothing in the Snowden leaks to prove that the actual crypto algorithms have been weakened. As far as anyone knows all that NSA has done is try to spread the use of it, which may be because they think that it is better.

[citation needed] on that one. Besides, "good ol' Bruce" has been, from the start, one of the people that kept warning against the use of Dual_EC_DRBG. Why use a slow and inefficient PRNG that has known biases (and possible number-theoretical backdoors), when you can use something more extensively tested (i dunno... Salsa20 or whatever).

Look, either Dual_EC_DRBG is a decent and secure PRNG, within reasonable parameters of computational complexity, or it's not. If it is, why the fuck is NSA paying security companies to adopt it? If it's that good, it should stand on its own and surely people will naturally adopt it (similarly to what happened with DES).

The fact that NSA has paid RSA to give priority to this PRNG is HIGHLY suspect, to put it mildly.

In a way this is no different than the fixes they made to make DES proof against differential cryptanalysis. Everyone suspected that NSA had weakened DES when in fact they made it stronger, but it took 15-20 years for people to see that.

Back then, people _suspected_ that DES might contain a backdoor. Today, we _know_ that Dual_EC_DRBG contains backdoor-like properties: it's not simply a suspicion. Do you understand the difference, or do you prefer to keep invoking this flawed comparison?

Since you like talking about DES, shouldn't you also refer how the US gov, back then, artificially forced DES key length to be ridiculously low, to the point where the keyspace could be directly bruteforced? Oh, let's not talk about that small detail...

For all we know the elliptic stuff only looks like it might be weak, but it may be perfectly fine and strong, but it may have been chosen since the form looks weak as a troll against anyone that would try to crack it. Square the circle, you can do it!

Hello? Are you paying attention? Dual_EC_DRBG has been SHOWN (not suspected) to display biases and to be particularly slow for the quality of its output bitstream (AND display backdoor-like properties). It's not optimal or transparent, and it's certainly NOT "fine and strong": it's shit.

A five-year-old could make a better PRNG using any vaguely-decent stream cipher, block cipher in counter mode or cryptographically-secure ha

The NIST/SECP curves are NOT safe. They were generated by the NSA, and they need replacing. http://safecurves.cr.yp.to/

For all you know they have generated those curves for the same type of reasons they replaced the S-Boxes in the original DES encryption - to strengthen it and protect the cipher against attacks they knew about but the public didn't know about. That's why when the differential cryptanalysis was discovered outside NSA it broke a lot of ciphers, but not DES.

Either way, we know the NSA generated it to ostensibly be random but really satisfy some very specific unknown conditions: that alone is reason enough to not trust it.

And if NSA knows about the math savvy Russian/Chinese attack against EC and your curve isn't selected to be proof against it? Poof! One question - if they know of a vulnerability, why would they make it a government standard for everyone to use? That would make US government crypto vulnerable too.

What a non-story. The flaws in Dual EC DRBG were widely published shortly after release.

The backdoor was first published by Dan Shumow and Niels Ferguson in August 2007.

Bruce Schneier wrote the same year:

My recommendation, if you're in need of a random-number generator, is not to use Dual_EC_DRBG under any circumstances. If you have to use something in SP 800-90, use CTR_DRBG or Hash_DRBG.

This was common knowledge if you had more than a passing interest in cryptography. I think TFA is mistaken when it says that it didn't get enough attention. The reason academics didn't take it more seriously is that it was seen as so obvious, it was mostly harmless shenanigans.

You would only use it in a serious cryptographic product if you were an incompetent crackhead, or if the NSA had stuffed your ass full of money.

Incidentally, RSA, the large security firm, shipped it in a serious cryptographic product for years and years.

My fast poly1305aes library is in the public domain. You can and should include it in your own programs, rather than going to the effort of linking to a shared library; the compiled code is between 6 and 10 kilobytes, depending on the CPU.

Of course, it being in the public domain, this is merely a suggestion, and, as a developer, one could basically use it in whatever way one sees fit (although djb's advice does seem quite reasonable).

chacha20 is a variant of Salsa20. There's also XSalsa20 that uses 192 bit IV.

ChaCha20 is great, I've been using it for the past year and with it being proposed for TLS with the IETF, it's very good for all of us. The world is waking up to the NSA bullshit and we're seeing some of these other standards getting some attention, especially away from anything NIST related or US Government standards related. Salsa20 was submitted and was a finalist in the EU encryption standard. I don't think we'll see the death of AES anytime soon but at least this gives us some alternatives. I'm going to wait for the code to stabilize a bit and start turning it on in my Apache configurations...

The algorithm is virtually identical, with a minor tweak of the matrix and round function to improve diffusion and map better onto SIMD operations.

He's always insisted that his qmail binaries get installed under /var/qmail,

Not true. He used to, but he has since placed qmail in the public domain, so you can do whatever you want.