Posts by Michael Wojcik

Re: What's that?

I dated Miss Placing for a few months in high school. I was very fond of her too.

Re: No iPhome ==No stalking

Your phone, my phone, everyone's phone is a "lost item detector".

Mine isn't, and indeed this is one of a number of reasons why I don't buy Apple devices.

If my phone is lost, it stays lost. And locked. As it happens, I have never, in a couple of decades of owning mobile phones of some sort, lost one. Nor did I ever lose the pager I had before that. But if I did, that's a loss I'll live with.

I've read Matt Green's speculative piece on how Apple's "Find My" feature works. Green is a smart guy and a good security engineer and cryptographer, and he thinks Apple's solution is probably pretty good from a security point of view. But it's something I, for one, do not need and do not want.

Yes, the issue is aggravated by AirTags because they're readily available, easy for non-technical attackers to use, and make use of Apple's device network. There may be no qualitative difference between an AirTag and many other types of trackers for this (ab)use case, but there are quantitative ones.

That said, I don't really see how those might be actionable under US law. IANAL, but it really seems like this is a revenge effect that it would be difficult to hold Apple liable for. It's not designed primarily for illegal use, and it doesn't seem to directly violate consumer-protection and similar laws.

I quite dislike this sort of device myself, and I have tremendous sympathy for anyone who's harassed or attacked in any way with the assistance of one. But I can't see an effective legal argument against them.

Re: Just a small point

Statistically, in the US Federal courts, criminal bench trials have better outcomes for defendants than jury trials do.

I'm not a huge fan of go, but I don't see it as responsible here. It correctly detected an index-out-of-range and raised an exception. That's a good feature.

The problem is the developer, who didn't catch the exception and handle it properly (i.e. by aborting the operation and returning to a known state).

Re: in a state of general functional failure

I suspect the problem is they relied on web services provided by FTX or FTX.US, most or all of which are apparently now broken. Molly White reported that NFTs issued using the FTX.US platform were broken by the update the FTX.US's website that posted the bankruptcy notice.

(I'd make a web3 joke, but my guess is these were all regular old web 2.0 RESTful or RESTish JSON services.)

Re: B S Johnson.

Musk with a direct brain-to-Twitter interface. It doesn't bear thinking about.

Re: Doing Agile

"Move fast and break people."

Re: Not if you want a decent quality product that works properly.

Yes, it is. Plenty of organizations do it. My teams do it.

I'll note that "move fast and break things" is not an Agile tenet, and has no place in good Agile development.

It wasn't pointless. It was a great example of why people should use OS/2 instead.

(Yes, Linux, FreeBSD, OpenBSD, etc were also available. Circa 2000 I was using a Thinkpad with multiple boot drives sitting in my computer bag, so I could shut down, swap drives, and use OS/2 or Linux or NT [hadn't updated to 2K at that point] as need arose. But Linux and the BSDs weren't easy for non-technical folks at the time.)

I watched a couple Strongbad emails just the other day. They're on YouTube. (Obviously without the interaction, but they've done a pretty good job of integrating the easter eggs into the videos.)

I think you owe children an apology.

Re: "For a quantum computer to be impactful"

what seems to be a very sophisticated form of analog computing

All physical computers are "very sophisticated form[s] of analog computing" when you get down to the metal. That aside, your description really does not apply to general QC. (It does to things like D-Wave's adiabatic machines, but those aren't general QC and are irrelevant here, and arguably everywhere else.)

If you look at algorithms in BQP, you'll see they are quite definitely discrete. They can be implemented just fine on conventional digital computers; they just don't have any quantum advantage there.

We already have working candidates for quantum advantage, so it's quite possible we will eventually have working general-QC systems which can solve a relatively small set of problems someone actually cares about, but which are intractable for conventional computers. Though what we're closest to right now, from the papers I've read, are solving problems mostly of interest to people trying to build QC systems. Still, things like (small but still intractable) particle-physics simulations aren't out of the question within a reasonable timeline.

That said, I am dubious about the economics of general QC for anything other than some fairly narrow primary-research projects. At this point, from what I've read, I don't have a lot of hope for commercially-viable systems for the sorts of business problems which could benefit from quantum advantage. By and large conventional asymmetric cryptography has little to worry about, for example; it just won't be practical to use Shor's algorithm to break RSA or ECC keys in bulk. (Specific high-value targets might eventually be vulnerable, and there's good reason to research and standardize on post-quantum cryptography anyway. Plus that's nearly a fait accompli at this point, and we've learned a lot of interesting things about codes and lattice problems and the like along the way.)

Re: English Translation

We know a great deal about what GQC is, and we know a number of things it could be good for, if the scaling and error-correction problems can be solved in an economical manner. It could be quite useful for certain types of physical simulations, for example.

People whinge when the Reg prints stories about QC enthusiasts making ridiculous claims, but they carry on just as much when it prints an interview with someone who has sensible things to say on the subject.

Re: Perfection

Uh, yeah, I think we all caught that. But there was a lot of rather odd and inexplicable waffling around the embedded Adams references. It's really not obvious what OP was trying to say.

Re: Perfection

The perfect quantum computer has all the answers.

Uh, no, no it does not. What in the world are you on about?

Any sufficiently powerful formal system can express undecidable propositions. In fact, the vast majority of the propositions it can express are undecidable, per Chaitin's proof of irreducible truths.

In the physical realm, there are questions which run into essential physical limits, such as Heisenberg uncertainty.

No quantum computer of any sort, regardless of "perfection" (whatever that might mean in this context), contains the answers to such questions.

Re: Worst code I ever saw...

Agreed. I presented on this very subject at Computers & Writing (or maybe the Association of Teachers of Technical Writing conference) some years back. Code has multiple audiences.

Re: Worst code I ever saw...

It's true there's no point in using a long variable name if it doesn't mean anything.

I still occasionally have to work on a component written in COBOL with variable names like "working-storage-6-bytes". Completely correct, completely useless.

Re: Worst code I ever saw...

Argh. This exact thing, several times over. I hear ya.

And those ad hoc binary protocols often have minimal redundancy, so corrupted messages aren't detected but processed as if they were legitimate, right up to the point where something breaks badly.

Re: Worst code I ever saw...

I know of plenty of algorithms that are very difficult for a maintainer to understand without additional explanation, even when implemented cleanly in a language with ample abstractions. Individual function points may be relatively easy to grasp, but understanding what they do in concert may not be.

Re: Worst code I ever saw...

I've read the arguments for "comments are a code smell", and it's an interesting philosophical proposition, but it utterly fails in practice.

The arguments are that code which isn't comprehensible itself needs to be refactored, and that comments don't get updated during maintenance (or even during initial development) and so you get skew between code and comments. More generally, it's that having different documents for different audiences – code and comments for developers, and just code for machines – increases the likelihood of error.

While these are all points with some validity, in the real world, there is always code which is too complex to be sure maintainers will divine its intention, regardless of how well it's structured; failure to update comments should be fixed by process, including code reviews; and humans can't perfectly emulate machines when reading code anyway.

"Comments are a code smell" is a sophomorism, the sort of reductive thinking you get from people who have some experience but not enough, and so still believe in elegant solutions to irreducibly complicated problems.

Re: Worst code I ever saw...

OP did say "two or three times".

I've found a compiler bug or two m'self, and a number of errors in language-implementation and third-party libraries. But I too have learned to assume it's my error first, and then when I can't find it, assume it's still my error and I just haven't looked hard enough. Only then try to reproduce the problem in some other way to show it's probably not my code.

One C library bug I identified many years ago I demonstrated by instrumenting the large software package that originally showed the problem to log its malloc/realloc/free operations; then I wrote a script that converted the log into C code that just duplicated those operations, after validating them for obvious errors like invalid realloc and duplicate-free. When that program reproduced the problem, I cut it down by bisection until I had a minimal reproduction, which turned out to require only 16 mallocs and 3 frees in a particular pattern.

Re: Explosive demonstration

Conservation of angular momentum: It's not just a good idea. It's the law.

Re: Trust and CA's

PKI was originally intended to be a decentralized system with each person managing their own keyring of trusted keys.

This is not historically correct.

There are many possible PKI architectures. PKIs were being discussed in public as far back as the 1970s when asymmetric cryptography appeared in the public research; it's hard to believe they weren't discussed in private at GCHQ (and possibly other government agencies) before that.

Some of the proposals were no doubt for decentralized PKIs, but many of them assumed centralization. Decentralized PKIs really only became a popular topic with PGP, which Zimmermann published in 1992.

PKIX was only standardized in 1999 (RFC 2459, currently superseded by 5280). But PKIX notes that PEM used a hierarchical PKI in RFC 1422, which replaced RFC 1114, from 1989 – three years before PGP's "web of trust". And PKIX (RFC 5280) itself allows alternative, non-hierarchical topologies.

PKI topology has been an area of research and debate for nearly half a century (at least). It's not a case of "originally it was going to be a people's topology, but then the Man took over".

Re: Trust and CA's

The problem with certificate trust is that the average person or even the generally technical person doesn't automatically know no one knows what's trustworthy

FTFY.

Not that "trustworthy" is a useful criterion here anyway. Membership in a root program for widely-used applications is far more complex than a boolean "Alice is trusted, Bob is not".

Re: Trust and CA's

The idea is that the CA's are so well-known and so universally trusted that the trust is implicit.

Perhaps at one time, and naively, but that's certainly not the guiding principle behind the major root programs or the CADDB now.

In contemporary PKIX, trust (for the root programs, etc) is based on continually satisfying various criteria (CA/BF Base Requirements and the root-program additional requirements, among others) and review, some of which is largely automated (e.g. CT), and some largely manual (e.g. MDSP).

Re: Trust and CA's

Whoever has access to that certificate's private key can sign any X.509 certificate in the world.

Anyone can sign any certificate they want. That's how certificates work.

A CA that's in the Mozilla root program that signs an entity certificate for an entity they shouldn't be signing for would be quickly detected by CT, and required to revoke that certificate and address whatever underlying issues led to signing it, or they'd be removed from the program.

I too believe there are too many CAs in the major root programs, but the situation is not nearly as simple as you make it out.

(And your scenario is wrong anyway. An entity certificate signed directly by a root would raise all sorts of flags. The actual attacks would be signing a new intermediate with the root, or compromising an intermediate's private key. But both of those are less likely than easier attacks such as legitimately signing certificates for entities with similar names, or simply compromising a legitimate host.)

Re: Trust and CA's

No one – not a single person – would be able to routinely verify TLS entity certificates under normal use. Few people can even list all of the required per-certificate and chain checks (name, validity dates, basic constraints, KU, EKU, CA/BF requirements, ...) and variants (SAN vs CN, if you want to support X.509v1 or poorly-issued v3; BC vs chain length, again if you want v1 support; entity-name wildcarding; ...), to say nothing of the shambling horror that is revocation. Even if you have a very restricted trust store and reject out of hand certificates that don't meet a stringent set of requirements, it doesn't scale.

Even moderate interoperability with PKIX is very much an arcane specialization. Applications which roll their own checks nearly always get it wrong.

I doubt any one person could run a root-certificate program competently, for general PKIX use. Look at what goes into the CCADB. Just try to follow MDSP on a regular basis, to say nothing of the CT logs and the like.

The simple fact is that the major root-certificate programs, and now the CCADB, are the least-terrible form of X.509-based PKI management for the Internet that anyone's been able to come up with so far, flawed though they are.

Re: Trust and CA's

I'd have much more trust in the security of communication with my bank if the bank would have given me a printed copy of the hashes of their certificates

And when those certificates are renewed, as should happen in about a year at the most, and is increasingly happening more often (short-lived entity certificates becoming the norm)?

They could give you the fingerprint of the public key, which would at least make a bit of sense. That's what HPKP did, though, and in practice it was a bit of a disaster, and is now deprecated in favor of CT.

And, of course, nothing stops you from implementing your own HPKP mechanism (which will have the same failure modes), or following the CT logs.

PKIX is a mess, and the major root-certificate programs include far too many CAs for my liking (though conversely concentrating too much of the CA power in a handful of entities – 90-something percent of TLS entity certificates are signed by one of five CAs, and nearly half by ISRG – is not great either). And initiatives like QWAC will make it worse. But making every end user responsible for deciding what CAs to trust 1) is already possible (you can change the trust stores for browsers and most other applications, aside from crap mobile apps that have much bigger security issues), and 2) is a complete non-starter for the vast majority of users.

Re: Available + Convenient != Sane

Lord, save me from armchair security.

What's your threat model? Online password stores are encrypted using a key derived from a master password. If the cryptography is implemented correctly – and there's nothing complicated here, just straightforward KDF and symmetric encryption – then it doesn't matter if the store is leaked. Here in the real world, symmetric encryption done correctly is not "broken". Just not gonna happen.¹

As for the "closed-source password manager contains a backdoor" threat: Under any reasonable threat model, for this use case, this looks overwhelmingly less likely than any number of other vectors, such as conventional keylogging malware.

Pretty much everyone I know, including the most technically- and security-inclined, are far more likely to neglect to back up a local password database, or neglect to synchronize changes between devices and so end up at least temporarily without access to some resource. Or to make provisions for password recovery in the event of their incapacitation or death.

This hyper-vigilant approach to password management misallocates resources in every version I've seen described. It's iron bars across the front door while leaving the back unlocked. Or, really, the reverse, because password managers simply are not a common target of attack (because the reward for attacking them is low).

But, hey, I'm willing to be persuaded otherwise. Show me an actual threat model and reasonable estimations of risk.

¹The absolute worst case is probably AES-128 and a huge quantum computer (which no one has, and wouldn't be economical for this if it were), in which case you get down to a 2⁶⁴ work factor using Grover's algorithm. Go ahead, have at it.

Re: Closed source password managment is too risky

Exactly.

Comments that begin with "you can't trust..." are useless. Trust is a meaningless attribute if it's not qualified with the parameters of trust and the threat model.

Statistically speaking, the vast majority of computer users face a far greater risk from not using a password manager than they do from using a closed-source one with online storage. And even for those using a password manager, the risks of online storage are significantly lower than of losing access due to local equipment failure or loss.

My passwords are stored online and sync'd to multiple devices because I've evaluated my password-storage software and decided the risk of it not meeting that trust level is low. My master password, along with instructions for installing the password manager software I use, are printed on a sheet of paper my wife has tucked away somewhere. That's the most sensible password-recovery risk for me to take under my threat model. I trust my wife not to abuse that access; and if she did, I have bigger problems to worry about. I'm happy with the risk of someone unauthorized finding that sheet of paper, because I evaluate it as extremely low.

On the other hand, I also know the risk of local equipment failure is relatively high, because I've had that happen to me many times over the years, so it makes sense to hedge against that by using online storage and automatic synchronization.