XMPPwocky

Two things- one, as a sibling comment's mentioned, it absolutely includes implementation of cryptographic primitives too. There are quite a few subtle bugs (mostly, but not entirely, side-channels) that end up being utterly catastrophic.

Second - even using somebody else's (high-quality, trusted) implementation of (high-quality, trusted) primitives very much isn't enough to build a secure system that uses cryptography. The obvious example here is everybody and their dog going off to implement AES or something, not using a MAC ("we just care about secrecy, not integrity") or using a MAC wrong (e.g. MAC-then-encrypt), and then dying horribly to a trivial padding oracle.

Or, trying to build a secure transport protocol (i.e. a TLS-like API, where you just get "a secure socket" after doing some dance with certificates/keypairs)... you just encrypt (and MAC, this time) all the data before you send it out, and decrypt (and verify!) all data that comes in. But... wait, our API can't really handle that easily - we have to write the data out to the network in chunks. So, hm, encrypt and MAC each chunk? Oh, then chunks can be rearranged in transit, so we'll put a counter in there. What if the counter wraps around? Do you abort, or do you just reuse old counter values? Do you get a different session key for the same (client, server) pair- if not, is that an issue? Suppose you're using an AEAD mode, like GCM- how do you manage nonces? (If you reuse a nonce once in GCM, you often leak your authentication keys(!))

Hm, all of that sounds like ... a lot. So maybe we'll just sign+encrypt requests (and include our public key inside), and have the server sign+encrypt responses (to the public key we sent). Hm, but we need to tie responses to requests, though. So we'll need to put a hash of the request in the response. Ah, hmm, length extension attacks, right. Maybe GCM will save us? Hm, not sure... What if somebody wants to replay old content to us (send us an older version of a page)? Can they do that? Right, need to either include some "challenge"/nonce in requests, or at least make sure session keys are unique per-request. What about possible reflection attacks - if we send the server its own public key as our public key, does that cause any weirdness? Oh, what is a public key, anyways? If (God forbid) you're using RSA, does that include both the exponent and the modulus, or just the modulus? If you do a key exchange (e.g. for forward secrecy), who picks the parameters- are they just fixed?

Cryptography is the sort of thing that almost actively resists abstraction, and it's really tricky in a way that's hard to appreciate. It's a world where you find a claw hammer and use it to remove a nail from your floor- maybe even looking on CarpentryOverflow first to make sure a claw hammer can be used to remove nails from floors- and it works fine, so you then go to remove a nail from your wall and discover that this makes the hammer burst into flames because, yes, most people think "claw hammers can pull nails out of stuff" and that's usually true but the unstated assumption there is that you're holding the hammer with your right hand and you're actually left-handed and it's a Tuesday in the southern hemisphere so you actually should have used a completely different tool or used a higher-level misuse-resistant nail-pulling API which does almost exactly what you want, but that's what you thought the hammer did so...

Offensive or defensive? For offensive (at least in the non-classified space), major players include e.g. Riscure.

A fun historical quirk about chip-level security is that most of the experienced people and firms have at least some ties to cable/satellite TV piracy (on either side of that).

I'm trying to read this charitably but can't. As far as I can tell, they're describing the concept of "fuse some keys into chips" (and/or "use a PUF"?) and "do secure boot". Where's the novelty? All I see is PR and bad, bad vibes.

Is there a decent technical document available that actually describes their improvements over the SOTA? Without that, the impression I get is that somebody is trying to dazzle non-technical investors with bullshit.

"Not to mention you will never--and I mean never--get people of a certain temperament to go along with an ever-changing set of rules designed to inflict zero emotional distress."

Why not? Because they'll throw tantrums, whining about how it's just so unfair that they can't call people stupid? Too bad. They can suck it up and do their jobs- a part of which is effective communication- or they can leave.

For folks who have actually set up srsRAN for anything besides a trivial configuration w/ one eNB and manual management of most things (and even then), the value-add of having Amazon worry about most of that stuff is clear. It's, ah, ... complicated.

This is a bit like responding to, say, the original announcement of EC2 with a link to download a Linux distribution.

"This is valuable work in the economy because you want [...trimmed...] people who are good at running businesses to do that once it has roots."

In my experience, things tend to get dramatically worse for users when a business is acquired or sold, not better. Long-term sustainability also seems to be significantly decreased by acquisitions, not increased- even when the business isn't closed outright (e.g. Pebble). And, from your second paragraph, it seems like you recognize this too. So, yeah, you might want people who are good at running businesses to do that - but selling a business does not seem to put people who are good at running businesses in charge of it. If anything, it's the opposite.

"Is there a footgun here that doesn't have an equivalent in GCM?"

Maaaybe- if you're doing the composition yourself.

You have to differentiate between the AAD and the ciphertext somehow, and you can screw that up (e.g. not putting the split location in the AD, sending it unauthenticated instead), while if you're using somebody else's GCM implementation they hopefully handle this correctly.

If somebody tells you to "do AEAD with this block cipher and this generic MAC", it's tempting to just ... find an implementation of the block cipher, find an implementation of the MAC, and play legos- neglecting subtleties like the split location, proper key derivation, etc.

It's far less tempting to implement GCM by composing implementations of CTR and GMAC because ... where would you even find an implementation of GMAC that's not part of a GCM implementation anyways?

"LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run."

If attackers who cannot add a comment to their exploit are in your threat model.

Personally, I've been using a browser extension that blocks JS unless it has a comment reading

> This code is NOT evil or malicious!

at the top. Haven't been hacked yet!

probing silicon is just hard and expensive, not impossible! - though those might be similar enough for most purposes

While ECC memory is probably important and probably better than nothing, if there's one thing we've learned about Rowhammer it's that the obvious mitigations that "should" stop or detect it often fail to a clever attacker.

Just the first thing that popped into my head, but: say you watch the ECC correctable error rate over time, and somehow (not so easy!) determine which process is causing those errors. You forcibly kill the process and log a message about it, and also terminate/notify processes potentially affected (say, send them a SIGBUS or something and unmap the pages containing the affected data).

I, a "clever" attacker, use this to leak out your secrets- I do my hammering juuust right so that, if some secret bit is 0, your hammering flips ECC bits, while if it's 1 your hammering doesn't affect things. Lovely little side-channel.

Universal memory encryption and authentication seems to be the only sure way out of the cycle of "attack, mitigation, attack the mitigation", and it's already starting to roll out.

"As long as it's better than the average driver, it's an improvement."

Careful- this is true if interpreted juuust right, but it's subtle.

Ultimately, you care about, roughly, the net decrease in Bad Things (injuries, deaths, property damage, weighted however you want) (and possibly also the net increase in Good Things (people being able to get places, mostly; otherwise, an excellent FSD system is one which simply stays in park and refuses to move!)) that results from the deployment of an FSD system.

That looks roughly like the sum, across all trips, of "expected Bad Things if FSD was available as an option for that trip" minus "expected Bad Things if FSD was not available".

The key here is considering each trip as a choice between FSD and non-FSD and /then/ averaging. You can't just say "FSD's per-mile accident rate is lower, so it's safer"- that misses a lot of important effects!

For example, consider selection effects related to weather and road conditions. It's easy enough to imagine an FSD system that falls apart entirely in bad weather, but works alright (but worse than a human driver!) in good weather. Let's say it's got 0.1 Bad Thing Points Per Mile (BTPPM) in good weather and 100 BTPPM in bad weather. But human drivers also do worse in bad weather, naturally- maybe they've got 0.05 Bad Thing Points Per Mile in good weather and 10 Bad Thing Points Per Mile in bad weather.

Now, assuming the poor performance in bad weather is obvious to drivers, drivers will only activate FSD in good weather. So the measured BTPPM for FSD is roughly 0.1. Human drivers, though, still have to drive in bad weather sometimes - so you might see, say, 1 BTPPM from human drivers.

Even though human drivers are better than this hypothetical FSD system in all conditions, they look way worse!

And that's just one effect- here's a related, but distinct one. Take the same example from before, but now the FSD system matches the human in good weather and bad weather (0.05 and 10 BTPPM) and, in awful weather and road conditions, where the human might have 1000BTPPM, FSD manages just 100BTPPM.

The FSD system's performance matches or is superior to the human in all situations. Surely this leads to a net decrease in Bad Things?

Not necessarily- what if people take trips in awful weather at 100BTPPM which they wouldn't take with a human driver at 1000BTPPM? (And this assumes people aren't lulled into a false sense of security because they know FSD is "safe", leading them to underestimate the risk in awful conditions). This is where you have to weigh in "how much benefit does taking this trip in the first place provide".

And one more thing: remember you have to consider the vehicle. Any vehicle with FSD can and would almost certainly (if it's human-drivable at all) provide very sophisticated ADAS features when driven by a human, and would likely be new enough to have quite modern safety features. So you have to remember to not just think about "FSD accident rate per mile v.s. human"; you do have to make sure to compare within the same vehicle.

"Better than the average driver" could be interpreted to take all this into account, but the straightforwards interpretation ("lower accident rate on average") doesn't, and can be surprisingly misleading.

"Imagine being in Minecraft, then walking your avatar through a portal that takes you into Roblox. Or more likely just hitting a button and being there."

Microsoft has actually been experimenting with this technology for a while - their implementation is quite sophisticated, and it's shipping in Windows now. You can actually try it out today: open Minecraft, then press the World Switcher hotkey combination (press the Tab key while holding Alt), press the Windows key, type "Roblox", and press Enter. If done correctly, your avatar will now be in Roblox!

It's pretty groundbreaking stuff, to be honest. Under the hood, the old universe is dynamically unloaded (possibly swapped out to disk) while the new one loads in. And, even better, if you press the World Switcher hotkeys again, you'll be right back in Minecraft - exactly where you left off.

...

Of course, I'm sure you meant that you'd somehow share information between Minecraft and Roblox- I'm sure you'd agree that arbitrary in-game items are unlikely to be transferable, but at least avatar appearance, surely? Well, hmmm, that'd make both games look worse, with awful art-style clash. Well, I guess you could store a few parameters and transfer those, and let each game interpret them to render an avatar that fits in the game's style?

... Ah, I've just made Miis again.

Okay, well, hm, if transferring avatar appearance isn't especially interesting, what about stuff that doesn't directly correlate to anything in-game? For example, the social graph, friends list, communications. Imagine being able to see what worlds your friends are in, talk to them while in your current one, and join their worlds with just a cli-

... oh, that's just Steam and Discord.

So... what's new, here?

The second half of that summarized: if you want to do cryptographic voting, OK- but print out paper ballots too, with both the votes in human-readable format and a QR code or something containing a hash of the protocol transcript or something that allows confirmation that the cryptographic vote matches the votes printed on the paper. Then do risk-limiting audits.

Right - it seems like at most what you want is a Merkle tree published at the end of the election, with all counted votes (in a coercion-resistant way, using the mechanisms described). Need to order events to support a more complicated protocol? Do a "Merkle linked list" (i.e. a blockchain-ish thing but without a consensus mechanism, like a TPM PCR+audit log combination).

Why do you want to use a public blockchain? Well, they try to explain that.... try.

"So why is a blockchain better than a special purpose bulletin board? The answer is: setting up a k-of-n system that's actually trusted is hard, and blockchains are the only system that has already solved it, and at scale. Suppose that some government announced that it was making a voting system, and provided a list of 15 local organizations and universities that would be running a special-purpose bulletin board. How would you, as an outside observer, know that the government didn't just choose those 15 organizations from a list of 1000 based on their willingness to secretly collude with an intelligence agency?

Public blockchains, on the other hand, have permissionless economic consensus mechanisms (proof of work or proof of stake) that anyone can participate in, and they have an existing diverse and highly incentivized infrastructure of block explorers, exchanges and other watching nodes to constantly verify in real time that nothing bad is going on."

"anyone can participate in" is absolutely hilarious in this context. It's true, in the sense that pretty much anybody can buy a few kilograms of gold- if they have the money. Proof of stake is the most obvious here, because it's literally "the more money you have the more power you have"- there's SOME argument that this makes sense when the decisions made by stakers directly relate to the value of Ether, the idea being "rich person won't try to manipulate consensus, because that would make them much less rich" (especially if they actually get slashed). i.e. they have a stake in keeping consensus fair. But doing real-world elections breaks this entirely. Proof of work functions similarly, just indirectly, and also while spewing CO2 into the air and sucking down semiconductor manufacturing capability.

Now, a common answer is "well, yes, but we could detect that manipulation happened after the fact, and then re-hold the election or whatever, possibly slashing malicious validators if we can somehow encode that into the protocol at a lower layer". Congratulations, you've figured out why blockchains are useless here. The actual security comes from being able to detect fraud- and a single Merkle root published by the government per election (and signed, so any forks could be immediately detected and proven bad).

In other words, you want Certificate Transparency, not Ethereum. CT solves exactly the problem Ethereum tries to solve here, and does it much better, and without the obvious conflict of interest cryptocurrency voting advocates have (that if a government did use, say, Ethereum for elections, it'd drive the price way up, so anybody advocating that who also holds Ether has a bit of a credibility problem right out of the gate!)

And this is all predicated on cryptographic voting being a good idea in the first place - in the short term, it's just not. You can verify the protocol, but you can't verify the endpoint- are people going to vote on their own devices? Just wait til the first claims (justified or not) that a major botnet flipped votes undetectably (and coercion-resistance guarantees that it really can be done undetectably). Or maybe on voting machines like we have today? Take a look at what happened to Dominion last cycle- so much for making elections more trustworthy.

Paper is actually incredibly useful here, because it doesn't run code and everybody knows it. (You could say "oh this CPU has all its code in mask ROM and the code is formally verified" and maybe I could confirm that, but most people could easily be convinced, understandably, not to trust me). Voting machines that print out your vote on paper that goes into a box, in sight of the voter, where the voter can read their paper- that's brilliant here. Can you attack that? Sure- switch out the boxes when nobody's looking, etc, etc.

But if I see, on the screen of my phone, "vote confirmed for Candidate A", for all I know my phone's actually sent to the server that I voted for Candidate B. And coercion-resistance requires that my phone can't ever prove to me that it really did vote for Candidate A - the phone's the actual voter here, not me, I'm not participating in the protocol. I'm just providing my phone some private keys and, on an unrelated note, giving it touchscreen input- nothing ties the two together. This is really important to understand. Your device is the voter in cryptographic schemes like this. You just tell it who to vote for, and trust it when it tells you it voted for them. (There's a workaround here but it has UX problems that seem to make it a non-starter too.)

If I see, on paper, that my ballot says "vote for Candidate A"... well, that's what the paper says. If somebody looks at the paper later, they can be pretty sure that's what I saw on the paper, as long as nobody has messed with it in the meantime. And to ensure nobody has messed with it... well, we have hundreds of years of experience figuring that out. This is the key- paper that is later counted (or even only counted randomly to confirm electronic results) binds feedback to the actual voter with the vote. On a phone, network traffic is NOT bound to touchscreen input or display contents, and it can't be without breaking coercion resistance.

> A simple approximation for environmental damage is the cost in $.

Neglecting externalities seems like the exact opposite of what you'd want to do in a discussion about environmental impact.

Except that:

1. difficulty calculations only happen every 2 weeks - so this would result in a comically bad UX where your transactions confirm dramatically faster or slower depending on the weather

2. the network security provided from mining using electricity is directly related to the opportunity cost of using that electricity for mining. If energy was otherwise going to be thrown away, the security provided from mining using that energy is zero.

This is untrue, of course.

51% attack resistance requires that mining be resource-intensive and have significant opportunity costs. Otherwise - if mining is not costly and wasteful- it's not costly for an attacker. If electricity prices went down to 1% of their current value tomorrow, miners would need to increase their electricity consumption by approximately 100x, or network security would suffer.

To the extent that energy or resources used for mining are free, or surplus (would otherwise be wasted)... that mining activity provides no security to the network.

This is the same reason advances in miner performance (e.g. better ASICs) don't provide more network security. Miners mine faster, but any attacker would have access to the same technology. The only thing that can actually make the network more secure is using more scarce resources - whether directly, .eg. via energy usage, or indirectly, by manufacturing ASICs, etc.

Bitcoin mining is not resource-intensive in the sense that, say, aluminum smelting is. The thing about aluminum smelting is that if there's efficiency improvements, that's good! That means more aluminum from the same limited supply of free/low-cost/surplus energy. I like aluminum! But when somebody finds a way to, say, double the hashrate-per-watt you can get mining Bitcoin... the hashrate increases, but the network-security-per-watt stays the same. It has to.

It's not resource-intensive in the sense that automobile transportation is. If cars get more gas-efficient (or energy-efficient in general), awesome! Everybody's life gets better. If Bitcoin mining gets more efficient... miners just mine more. No extra security. No actual reduction in resource usage.

Assuming that miners mine when it's profitable (+EV) and don't mine when it's not profitable, Bitcoin's difficulty adjustment system implies the following: "The sum of all transaction fees and the coinbase reward for each block equals, on average, the cost of the resources used by all miners during that block period plus a small profit."

In other words, with a 6.25BTC block reward at current prices, every Bitcoin block requires burning about $250,000 in resources- or about $1.5 million an hour.

Now, that doesn't have to be electricity. If we discover free energy tomorrow and electricity prices go to zero, the resources used would likely switch to be those used in miner ASIC manufacturing- since every ASIC made would be a literal free money printer. But you'd still need to (amortized across the ASIC's life, of course) use resources worth about $1.5 million an hour on network security - or accept that network security is weaker. And to be clear, that's "worth" including things like transportation costs- natural gas may be worth $X per BTU, but natural gas out in the middle of nowhere where it'd otherwise be flared is worth far, far less, and using it thus provides far less security.

So, Bitcoin is either insecure or wasteful on an almost unimaginable scale - and probably isn't even wasteful enough today. (And no, that's not an XOR.)

The only way I can see not to wind up at this conclusion is to argue that markets aren't even weakly efficient.

I don't think it's entirely unreasonable to feel weird about watching old DVDs of the Cosby Show, for example. With the "benefit" of context, the vibes are sort of irrevocably off.

To be clear, most of the folks doing this sort of security research are probably worse programmers than your average senior dev, or at least not noticeably better.

It's a distinct skillset.

To whatever extent they might build software that's more secure than the average dev's, that really comes down to applying their security skills and toolset to their own software- thinking like an attacker- not any particular skill at software engineering.

Paying somebody to write buggy code on purpose is a bit like pissing into the ocean.

"I work on ads at Google"

why?

If your only selling point is lower fees, why don't I just make a site that takes 0.9% and eat your lunch?

So they'd have to be socketed? That means no HBM, which seems unfortunate. (If you mean just replacing the entire card... why not replace the entire console? All you'd be getting from the host system would be power (probably as 12V, so you need several DC/DC converters on the card), storage, and networking - besides storage, all of these are commodities; and for storage, existing consoles already support swapping drives out just fine.)

Aren't you just suggesting "big Tegra"? If the host PC isn't providing anything but maybe storage and networking...why not just buy a console?

None of those questions seem to be relevant to whether or not there was some sort of smart device involved.

> They advocate immediate disclosure of zero day exploits found by government

How do you think governments find these vulnerabilities? Accidentally, under the couch cushions?

What you actually seem to be proposing- in practice- is a ban on government-funded vulnerability research.

Your article seems to directly contradict the idea that any sort of IoT / "smart" device was involved:

> Fazio Mechanical Services just issued an official statement through a PR company, stating that its “data connection with Target was exclusively for electronic billing, contract submission and project management.”

> Most people would want to know a backup is corrupt before they started the restore, not partway through it.

Yes, which often makes OpenPGP a bad choice, because of how it has to authenticate things (requiring multiple passes). Many implementations of OpenPGP will happily release unauthenticated plaintext to the caller (and then fail at the end when the MAC fails- too late if you piped that to tar!) - there isn't an efficient way to do better than this with OpenPGP, because...well, it isn't very good.

DISCOUNT REAL 𝐑 𝐎 𝐋 𝐀 𝐗 AT THE ONLINEE PHARMACY

CLICK AND WIN --- YOU HAVE (3) NOTIFICAIFIOTIONS

http://www.5z8.info/fakelogin_q3h7ka_nic_cage_naked

> Bro hardware with improper software can break or kill.

To be fair, this doesn't seem to have stopped Tesla before.