I've watched the videos
Yes, but did you read the article?
For the motors that are exposed to salt water, APL applied commercially available protective coatings. The team tested the performance of the motors by submerging them in salt water. Two months later, they showed no sign of corrosion and continued to operate while submerged.
MAC address lockdown is practically useless on its own (see: ARP poisoning attacks & DHCP spoofing), not to mention completely unscalable.
Network isolation & good firewall rules at the demarcs are important, but they aren't a panacea.
slacka is correct, protecting networks after a physical intrusion has occurred is very difficult or impossible.
802.1X can help when it comes to the scalability of port authentication, and DHCP snooping and dynamic ARP inspection can both help in securing networks against ARP poisoning & DHCP manipulation, but they still leave some holes open.
802.1AE ("MACsec") theoretically mitigates a whole lot of attacks, but it's difficult to deploy to end-user devices. Want to attack a MACsec-protected network? Just look for the nearest printer which likely doesn't support MACsec and has an exception configged for its switch port.
This doesn't even begin to address hardware keyboard loggers, cameras, or TEMPEST attacks, all of which are perfectly capable of grabbing up user credentials.
In short:
1) Security requires a defense in depth approach, and physical security is an important part of that defense.
2) No matter how smart I may think I am, there's usually someone smarter who can think up some attack I haven't.
3) The more security you have, the more capex, maintenance and failures you have to deal with -- it's a always a balancing act.
More on topic though... as others have said, dumb article with no new revelations....
Agree with everything else you're saying, except perhaps this:
They also had to move the bot so it would fit in frame from that shooting location, that's why it's on a different bench from when the local news recorded it earlier.
The "beating" would have occurred on-camera (IIUC) had they performed it in the same place as it had been found. I'd venture that they weren't in possession at the time of the staged beating because it was a few nights after it actually occurred, so they just fake-beat a non-existent bot (plus the two prop arms—who knows what they actually were) just beyond the camera's visibility.
As I said before, I think it's more likely that they just want to troll the interwebs than actually release footage of themselves destroying property. Just a guess, though.
Certainly looks staged, I agree.
For example, why is the sky pitch black despite it purportedly being 5:45 AM (well into civil twilight, just 15 min. before full sunrise)?
The remaining question is: are they small d-bags (staged a fake destruction after some unknown party performed the actual destruction) or big ones (did the actual destruction themselves)? I'd guess the former—in an effort to make others look foolish, that seems to be more their M.O., but the latter wouldn't surprise me all that much either....
Perhaps you're mistaking RSA with DSA.
DSA and ECDSA do share a lot. To construct both of these algorithms, you start with an abelian group (a set of elements (e.g. integers; one of these becomes your public key) plus a "group operation" (e.g. multiplication)) and a "trapdoor operation" which is easy to calculate in one direction, but believed to be hard to calculate in reverse. The trapdoor operation is a repeated application of the group operation.
With DSA, the abelien group is a set of integers between 1 and p-1 (p is prime), the group operation is integer multiplication modulus p, and the trapdoor operation is integer exponentiation modulus p. (Note that exponentiation is repeated multiplication.)
With ECDSA, the abelien group is the set of points on an elliptic curve over a finite field, the group operation is something called "point addition", and the trapdoor operation is something called "scalar multiplication" (which is just repeated point additions).
The rest of the DSA and ECDSA algorithm is the same, and can be defined by steps such as "repeat the group operation x times" which is performed using one of the two group operations above depending on which algorithm is being used.
RSA on the other hand is a completely different beast, and not at all similar to ECDSA.
the only difference between RSA and elliptic curve is the equation you use for the curve.
ECDSA uses a curve. Neither RSA nor DSA uses any form of curves or points.
Elliptic curve obviously uses the equation for an ellipse.
Elliptic curve crypto uses the equation for, well... an elliptic curve. An ellipse (oval), despite the similar name, is an entirely different equation.
FWIW I use Trendnet Powerline adapters where I have poor Wi-Fi coverage. This is an Ethernet-over-AC-power technology. Specifically, I use a pair of their 500 series. I just ran a quick test, and with a 1Mbps upload stream (from my PS3 location to my PC), I was able to pull a download stream of around 60Mbps - 100Mbps (it fluctuated a bit between those speeds).
I occasionally have to reset them when they seem to lock up (say, once every 6 months or so), but overall I've been quite happy with them.
If you do find a solution to your question for the audio/video/controls, I't definitely recommend a pair of these adapters versus any wireless option.
(Of course, YMMV.... if the two power sockets happen to be on opposite legs in a typical 2-leg 120/240V North American home, then the signal needs to go all the way out to the nearest pole-mounted service transformer and back, which will likely result in a slower speed than otherwise.)
NearlyFreeSpeech.net offers many TLDs (not all) for registration. If you use them for DNS, their config page isn't that great IMO (it's a bit slow and cumbersome), but I like just about everything else about them.
Relevant to TFA: you can configure how many "recovery actions," between 2 and 7 (default: 3), which are required before you're granted access to lost account credentials. They also offer a "scorched earth" option: if you lose access to your account, it's gone forever (any associated services will persist until the account runs out of funds).
Whatever conflict of interest may or may not exist at the ESRB (or MPAA for that matter) pales in comparison to the real issue those two organizations continue to perpetuate in the US: showing a little skin, talking about sex, and swearing is a sure way to get you an M or R rating, but gunning people down or beheading them is relatively acceptable behavior.
(FYI I'm not talking about a violent game's ability to influence the behavior of individuals IRL, which I believe is insignificant if it exists at all, I'm only talking about the ESRB/MPAA's messed up moral compass.)
These guys are crazy!
Please, whatever you do, avoid NFS at all costs!!!!
If the point of the IR lights is to overexpose a camera that's IR sensitive, wouldn't this light them up like a Christmas tree? I wouldn't think that the kind of person who wants to hide their identity would be interested in wearing a big neon sign that says "Look at meee!!!" to any security guards monitoring those cameras....
Keep in mind that this is crypto code, which often has different properties and requirements than other types of code.
For example, the count of bytes to store a private key, or a finite field element, or a hash output, etc. is hard coded and never changes. It would be akin to asserting that the sizeof a uint32_t is 4 somewhere in your code.... not very useful. Perhaps some defines would be nice from a documentation point of view, but that's more a style choice.
Input validation must be handled very carefully due to the possibility of opening up side channel attacks (anywhere you see a piece of code which branches depending on its input is a potential vulnerability for a timing attack, and is intentionally avoided by this library).
But the big reason I'm a lot less concerned than you are is simply the reputation of the authors, who are among the most talented cryptographers on the planet. It's not that they can do no harm (such hubris would be self-defeating), but rather that the likelihood of you or I finding some vulnerability with just a cursory glance seems extremely unlikely....
In addition to the various other oversights already mentioned, OP doesn't seem to understand Git (or perhaps SCMs in general) given that those (now revoked) keys are still on GitHub -- there was no need for a bot to be all that quick.
Although I wouldn't blame OP for any single one of these oversights -- nobody's perfect -- it's fair to say that it took a number of different oversights / misunderstandings on OP's part for this to become a real problem.
What are the options, then?
Even though option 2 works well for some projects, it's not always ideal. This doesn't seem to be a problem with a simple solution (and it probably doesn't help that not many techies are great at politics).
"Irrationality is the square root of all evil" -- Douglas Hofstadter
