BTW, FalleStar, I reported your attack to the Password Alert team. They've made a number of changes which defeat your attack as well as a large class of similar attacks. The new release hasn't been pushed out to users yet, I don't think, but I'd expect you'll see an update before too much longer.

The Password Alert team thanks you for your report. Actually, they thanked me, but I didn't do anything other than pass messages, so I'm passing it along to you.

Too bad there's no Vulnerability Reward Program for Password Alert :-)

RTFA. It doesn't log keystrokes, and doesn't send anything off your machine.

Some Javascript downloaded from Google scans all the text you enter, hashes it, and compares it with a locally-stored hash. It doesn't send any of what you type anywhere off your machine. Not wrong, or scary, and it's all open source so you can verify what it's doing. For that matter, you can use the Chrome dev tools to set breakpoints and step through it.

There have been some articles about this with respect to Google's cars, and making the cars act more like human drivers is a key piece of what Google is working on.

Here are a couple:

http://www.govtech.com/fs/news/Googles-Self-Driving-Cars-Learning-to-Deal-with-the-Bizarre-.html

http://theoatmeal.com/blog/google_self_driving_car

However that's about more subtle issues of body language and negotiation. As for the scenarios you cite, it's easy:

Most likely gently slow and stop. If it couldn't do that in time, it would go through. Remember that the self-driving car has 360 degree vision; so if what you're worried about is that it'll just suddenly slam on the brakes, it won't. It knows where the vehicles behind it are.

Give him space.

If you want to know, google it. There are a bunch of videos from Google, showing how the cars interact with pedestrians and cyclists. The article above from theoatmeal mentions that while the author was riding with it, he thought at one point the car was waiting when it should have gone, only to find out that the car had seen a cyclist approaching on the other side of a hedge. That's a case where the automated car acted different from a human driver, because it had more information than a human driver. And that was a good thing.

Actually, I don't think there are. Keep in mind that MapMaker isn't new; it's been open for years and working reasonably well. There's just been an uptick in usage (valid and vandalism) that has swamped the old moderation system. So, they need to improve the moderation system, then it'll be back on line.

No, Satoshi did not change any values in AES. Satoshi chose a less-common curve for ECC, nothing to do with AES.

Foolish, yes, but not completely retarded. If you look at the details, it's pretty clear that what they were trying to do was to build something really, really fast, so they could process huge volumes of packets on lower-spec hardware, with less generated heat, etc. There were valid reasons for putting in the extra work... but obviously the approach they chose was wrong.

I'm not sure what you're thinking of as "first" (which direction), but if you did something like this you'd want to make sure that AES, or similar, is what operates directly on your actual data. "Encrypting" the already AES-encrypted ciphertext with your homegrown thing can't reduce the security of AES, and can't expose anything via side channels because all it would expose is the AES-encrypted data.

OTOH, you're really, really unlikely to gain anything at all by doing that. If you want to defend yourself against an AES break, superencrypt with a different well-known and well-tested algorithm, ideally one that uses a very different construction.

However, if your system is insecure I guarantee AES won't be the reason. It'll be your key generation or key management practices, or misuse of block modes (e.g. reusing IVs or nonces), failing to authenticate, etc. And the non-experts who contemplate layering something on AES will almost certainly screw up some other piece of the puzzle and produce an insecure system.

Unless there's some interaction between the two, such that one reverses some property of the other, then the combination should be at least as secure as either. I don't expect that would be the case with any of the important algorithms.

However, you're not going to gain any security by doing that, either, unless you're hedging against the possibility that one of the two gets completely broken. I don't think that's very likely with something like AES. If you really want to make sure you've achieving good security, you should focus on the rest of what you're doing: encryption mode, source of randomness for IV and key generation, key management, etc. Those are the areas you're actually likely to have problems, not AES.

RTD has quite good service to DIA. When I lived near Boulder I almost always took the bus to the airport. It makes few stops, runs regularly and is inexpensive. If you haven't looked into it, you should.

No.

The statement is precisely accurate, not overbroad at all. Yes the suites were created... but not for production use. All of the bits and pieces were created first, then analyzed and attacked for years, and only then put into production.

And as the raft of SSL implementation and protocol bugs over the last year demonstrate quite conclusively, many of them are still put into production too soon.

Not if you care about security. What about side channel attacks? What about leaking sensitive data into the heap? What about performance? On various architectures? I could go on.

Merely compiling and generating correct test vector outputs is far from all an implementation has to do to be good. Luckily, there are good implementations out there, easily obtained and under generous licenses.

It's not the case for any people. You won't see professional cryptographers rolling their own crypto and using it, either.

I'm not a cryptographer myself, but I am a very experienced cryptographic security systems engineer, and I work with a bunch of serious cryptographers, who are well-published and extremely well-respected in academic circles -- exactly the sort of people who you'd expect to be most capable of designing and building custom systems. And you know what? They don't.

And I'm not just talking about creating new ciphers. Even when I go to them with novel requirements that seem to demand some sort of new construction using existing algorithms and techniques, the very first thing they do is go to the literature to see what has been done, how long it's been in use, how widely it's been reviewed and analyzed, etc. The less knowledgeable (like me, frankly, though I'm getting better) tend to start by cooking up some new scheme. Real experts avoid that if at all possible, and if they have to do something new they look really hard at how they can prove its security by reducing it to known constructions.

Even the guys who do create new ciphers do it with great care, often spending years designing and attacking and tweaking, and then their next step is to publish it so others can attack it. Only after it has survived lots of other review does anyone, especially the author, begin to trust it for real use. But the most common outcome, when something new is designed, even by serious experts, is that it gets broken shortly after publication. It's quite common for new algorithms and constructions to be broken at the same conference they're initially presented.

I reiterate: No one who knows what they're doing creates new crypto for production work.

Moreover, people who know what they're doing even approach implementation of known and trusted algorithms with trepidation! There are so many very subtle things you can get wrong. Heh, just last week someone pointed out that my implementation of a constant-time memcmp had a subtle bug that caused it to be not quite constant-time on some architectures. Novices have no idea why it even matters in crypto that memcmp always run in the same amount of time for a given buffer size, irrespective of the contents of the buffers, and assume that the C library's memcmp is fine. More knowledgeable engineers know why it matters, but really deep expertise is required to get it right. That's just one tiny example. My primary mistake wasn't the bug in my implementation, it was trying to write memcmp at all. I should have found a well-vetted implementation and used that.

Doing your own crypto is nothing like doing your own science or doing your own music. The thing about security is that it's only as strong as the weakest link; the tiniest crevice can give the attacker a wedge to bust your system wide open. Other fields are forgiving of minor flaws, you can do useful and interesting work even if it has some defects. In security, and crypto is often at the heart of security solutions, one tiny mistake can render the totality of what you did not only useless, but actively dangerous to your users.

If writing a good secure memcmp is too hard for an engineer with 25 years' experience, including 20 years doing cryptographic security, what does that say about trying to write something that doesn't appear to be trivial? Crypto is hard. Really, really hard. The more you learn about it the harder it gets, because you understand more about what can go wrong.

I agree, although I have a more optimistic outlook. The difference is that in the US the people actually do have a say. Our problem of late has been that a majority, or at least a large minority, of people have favored the "tradeoff", because they didn't understand either the costs or the benefits, and many others simply haven't paid attention, leaving only a fairly small minority opposing it.

I think the pendulum has begun swinging back the other way, though. It has a long way to go, but Snowden's revelations helped a lot, and if we can get a few more I think the people will become more cautious about their rights. In addition, the terrorism scare is dying down. Of course, the risk there is that another large and successful attack will bring that back.

In addition, we do have a legal backstop in the constitution. It takes a long time for that to take effect, as first the people who want to challenge the unconstitutional laws have to figure out how to attack them in court, then the challenges have to wend their way through the court process, which is lengthy. But although the wheels grind slowly, they do eventually get there.

Finally, we have another last resort that the Chinese did not have. Americans are armed. The weapons we have are mostly for hunting and sporting purposes, not military arms, but the differences aren't really that large in practice, at least compared to military small arms. In addition, the states are armed with heavier firepower, up to and including fighter aircraft, attack helicopters, tanks, etc. On top of that, our actual military forces consist of people who have taken an oath to support and defend the constitution, not the government, and many of them take it quite seriously. All this adds up to a citizenry that is capable of beginning the resistance, has an opportunity to convince states to bring their firepower into it, and will attract the sympathy of many in the armed forces.

Of course, I really, really hope it doesn't come to that last option. And I don't think it will. Either enough of the people will come around and the system will be changed via political and legal processes, or we'll collectively decide that we really do want our government spying on us. Either way, I'm confident that the will of the people will win out. Mostly, anyway.

In order to trade off some of A to get some of B, you have to actually get some of B. In this case, we've given a lot of A and gotten nothing for it.