Posts by Michael Wojcik

Probably not. Most users choose passwords that are too easy to crack, so even for salted cryptographic hashes the pre-image can be found for relatively small numbers of accounts quickly enough that it's not worth using specialized hardware. Just hashcat running on a vanilla PC is often plenty fast.

Good password verifiers use Argon2 (probably the best choice, when used with appropriate parameters), bcrypt, scrypt, or PBKDF2. An ASIC designed for Bitcoin-blockchain-hashing won't support any of those, and Argon2 in particular is memory-hard and so not amenable to compute-based hardware acceleration.

So the password-cracking use cases where a generic SHA1 or SHA2 hardware engine is useful are limited.

It breaks more than "some hacks". The query string is part of the HTTP specification, and stripping it will break some conforming sites. For some people that may be an acceptable trade-off. It isn't for me, not least because I have software I've written which makes use of query strings, and I'm not inclined to rewrite it to accommodate a user agent deliberately violating the specification.

But I haven't used Firefox since they broke my extensions, so I don't particularly care one way or the other. And since this is optional and off by default, I don't much care if Firebox gives it to the users and lets them make their own decision.

Re: Alternatively

It doesn't even need to be git. That's designed for a project on the scale of the Linux kernel, which relatively few of us are working at.

And more importantly, it's designed for a truly distributed use case. Most of the projects using GitHub are using it as a single central server, which is not where git has any significant advantages.

It'd make more sense to be using SourceForge and Subversion for that use case. Subversion's model is easier to understand (the vast majority of git users seem to have no idea of what its internal representation actually is) and better suited to the central-repository use case.

Most projects seem to be using git because most projects are using git.

Re: Others preferred

vim is my editor for all text-based files on all the platforms I work on that support it. (IBM mysteriously have not yet added vim to ISPF yet.)

I've been a professional software developer since '88, and had to use a lot of editors and IDEs before and since. I'm not saying I'd recommend anything in the vi family to anyone, but I've used vi, then vim (and gvim on Windows, due to some sort of occasional issue with running Windows vim under Cygwin bash that I can't be bothered to sort out) for too long to be inclined to switch to anything else.

Also, I hate every IDE I've ever used; none of them come close to the power of shell + my editor of choice + my debugger of choice + POSIX text tools + a decent build system and so forth. I really do not see the appeal of having a lot of not-really-very-good tools baked into the build system, when much better ones are available right there on the command line, and are trivially scriptable.

Re: Sell strike aircraft not spyware

Tu quoque fallacy. One bad act does not excuse another.

Re: "after two Walmart stores equipped with the panels caught fire"

Didn't the whistleblower's report say the installers were covering non-functioning cells with black electrical tape, leading to overheating? I know, I should look this up before posting, but, you know, Internet.

Re: Yay, we have finally reinvented the terminal

Yeah. And X11 was used properly in the days of X terminals, with mostly protocol messages flowing between the client and server, and let the ddx layer render. Very little of this QT-style "I'll do my own rendering into a bitmap and shove it over to the server" crap.

So you didn't need nearly as much network bandwidth. And since the primitives could compress a lot of information and rendering was slow compared to today's hardware, latency was less noticeable, too. If an xterm sent 800 characters in a single XDrawString to a server, it would have a little while before the next message needed to get there.

Oh, well.

Re: 56k

I remember using BBSes over 300-baud modems well, but that's partly because we use Teams at work, and it simulates the experience with great fidelity.

"hipster slang"? There's a big disparity between the demographics of the Occupy movement (which coined the "one-percenter" label) and the hipster subculture. The former was dominated by progressives, a significant portion of them older (about 20% over 45, according to the survey by Cordero-Guzman & Schultz), and mostly lower-income (about 85% under $75K/yr). Hipsterism is dominated by upper-middle-class and affluent teens and young adults, and is culturally retrogressive, with a postmodern iconography scavenged indiscriminately from the real and imagined past. There's little ground for calling "one-percenter" a "hipster" term.

There's no reason for a judge to avoid using vernacular terms to describe a defendant's state of mind when they express the appropriate idea; in fact, when they're terms that the defendant might use, they clarify the opinion by providing relevant connotations. Using them would be very weak evidence of bias indeed, and frankly I'm not sure how you would draw that conclusion.

Legal writing is often so stogy that it obscures its own meaning. The movement for more use of plain language in legal writing is of benefit to us all. It certainly shouldn't be obstructed by unwarranted shibboleths like this.

Re: Seriously, are programmers that bad?

I agree. I've been writing code in C since 1988, before the language was standardized. I had the original K&R book mostly memorized, and most of the C90 standard memorized; I reviewed the changes to the language in C94 (which admittedly wasn't much), C99, and C11. I've read the Rationales that accompany the standards. I've read (and re-read) a number of books on C development, such as van der Linden's Expert C Programming and Jones' The New C Standard.

I've written, tested, debugged, and maintained hundreds of thousands of lines of C, my own and other people's, most of it system software such as middleware and application engines. I've done device drivers, graphics kernels, compilers, debuggers. I've worked on embedded systems, micros, minis, mainframes. C is still the language I work in most often.

Software quality is one of my research areas; security is another. These are things of considerable concern to me. I do extensive refactoring and prefactoring of code to wrap the (very primitive) C standard library in higher-level abstractions and simplify implementing cross-cutting aspects.

I still make mistakes that the Rust ownership model and borrow checker would catch at compile time. I know that because I've written a little Rust and I'm gradually doing more of it.

I've worked with a great many programming languages, from pretty much all the families, from assembler (on a dozen architectures) through 3GLs, functional, OO, and multiparadigm languages. I've used scripting languages and data-flow languages and constraint languages and lots of DSLs.

Rust is pretty good. It makes a substantial contribution to improving software quality. A very disciplined C developer can indeed write C which is much, much better than run-of-the-mill C code; but automating the detection of significant classes of issues at compilation time is still better.

Re: Gold

Agreed. I never used an Acorn machine – there weren't that many of them this side of the Atlantic – but it's always good to read these accounts.

Re: Gatekeeping

And it's not like hobbyists don't have all sorts of ways to explore and tinker and make things. Just look at Hackaday or similar sites to see all the great things people are doing on their own.

If someone wants to play with custom chips, there are FPGAs, which will suit many purposes. I mean, most folks tinkering in the shed aren't looking to build thousands of commercial-grade CPUs to sell, so the performance and gate counts of off-the-shelf FPGAs would probably be fine for whatever experiments they want to do. Hell, simulators are probably fine for most of it. People have implemented SPARC-64 on FPGAs, for example.

It's really not clear what the hell OP was thinking people might do at home, but looking at the vast array of projects documented on "maker" sites like Hackaday I don't think individuals or even small teams would be able to be much more ambitious even with access to a fab.

Re: repeat after me

It's not always in key management. People make plenty of other mistakes, too. I note of the attacks listed in the article, none appear to be key-management vulnerabilities as such. They have a couple of oracles that leak key material, which is a protocol implementation error; they have integrity violations, which is separate from keying; and they appear to have a vulnerability which escalates the key-recovery attacks which may be due to the use of ECB mode. (I haven't read the paper and it isn't clear from the article.)

There are a great many mistakes people make. Many of them have to do with key generation, key hygiene, and other keying issues; but many do not.

Re: What exactly is new here?

It's also worth noting that the issues mentioned in the article – I haven't read the DARPA report – have all been documented in published research before. There were papers on Bitcoin network partitioning in Colyer's Morning Paper when that was still active, for example.

But reproduction and confirmation of results is useful, even if it isn't new to people who have been following the research.

Re: Back in the old days

I was writing X11 applications, window managers, libraries, and extensions in the late 1980s / early 1990s, and I didn't need a "wall" of documentation. There was book 0, the protocol (which was also the specification); book 1 for the libx11 API; and book 2 for the major widget sets, if memory serves. It wasn't something you'd slip into your hip pocket but it wasn't SNA, either.

Re: CDNs are evil!

Well, yeah. And the web was ruined by Javascript (and arguably by CSS, and even graphical browsers, though those are useful for viewing useful graphic assets like charts and plots). And the web ruined Usenet. And really with a few improvements to Gopher or WAIS we could have dispensed with the web in the first place. And GUIs ruined UIs. And so on.

As Nick said in Metropolitan, I'm not entirely joking.

But, curmudgeonly as I am, even I make use of some online services that wouldn't be feasible without CDNs or some other edge-delivery mechanism. (Someone else mentioned IPFS, but I'm dubious.) Could I live without them? Absolutely. Would I miss them if they vanished? Eh, a bit, but to be honest I'd miss good old fashioned paper books far more if I lost those.

Still, I can't pretend I get no value from CDNs. And I suspect that's true for the vast majority of people who do anything online.

Technically, though, OP is correct. That's not "intrinsic value". It's exchange value.

The problems with the cryptocurrency fans is, first, they're hoping the exchange value of the particular horses they've picked in a very crowded race for new, unregulated, volatile exchange media, many of them with various other unfortunate properties, will outperform the established top-down (i.e. government-issued) currencies.¹ And sometimes they do, for the short term. But it's a highly risky position to take – and the short term is the only term we've had with cryptocurrency. No one knows what that market will look like in ten years.

And second, cryptocurrency only succeeds as a medium of exchange (and thereby has exchange value) if you can actually exchange it for something with use value. Sometimes you can, apparently; that's what made the Silk Road successful. But I sure wouldn't want to depend on it.

So government currencies have superior exchange value to cryptocurrencies now, and they may always (with the possible exception of government-issued cryptocurrencies, which, ugh, I can't even). But they're not different in the type of value they have, just in the amount and liquidity of that value.

¹Of course cryptocurrencies aren't the only example of bottom-up consensus currencies, even in the modern era. There are plenty of groups of people in places like Papua New Guinea using those, and for a while in Somalian markets the merchants were circulating their own notes. But historically bottom-up currencies have only succeeded in fairly small markets where there was a strong in-group identity and widely-observed mores against exploiting them.

Someone's being a lawyer on the Internet!

Re: "it was compromised between December and April 2021"

It was actually some time between December 1970 and April 2021. Maybe multiple times. Maybe after April too.

In what context have you seen CAPTCHAs used as a security mechanism to prevent malware from impersonating you?

Every use I've ever seen of the damn things is an attempt to block bots from 1) creating accounts or 2) posting fake UGC.

CAPTCHAs were a bad idea when they were invented and have gotten steadily worse, because of course they degrade into problems which are easier for machines than they are for people. Anything that helps get rid of them is fine with me. (I am not an Apple user. Haven't liked anything they've done since the //e, and don't care for the corporate attitude.)

Re: Am I glad that I'm not in this circus

It doesn't entirely "get rid of the problem".

Using a private code repository that's not shared with people and organizations outside yours reduces the attack surface and risk quite a bit, yes.

Using an in-house code repository that's not accessible on the public Internet reduces it further. But as we know, the "egg model" (hard network perimeter, soft inside) fails all over the place, because some attackers do get in, and then they pivot and elevate. So security is improved but there are still serious vulnerabilities.

Using a code repository that is just a code repository and not some glorified all-in-one mess of repository and CI/CD system and code-review tool and problem-ticketing tool and probably there's a flight simulator in there somewhere, like GitHub Enterprise, considerably reduces the attack surface and further improves security.

Using a code repository where some developer hasn't broken the permissions mechanism with a random change that wasn't caught until an external security researcher looked at it improves security.

You can never get to absolutely secure – there's no such thing. But, yeah, not using public fucking GitHub certainly improves the situation.

Seventy-three million developers can be wrong.

Re: Portable Executable Format

the APE format leverages that by embedding a binary structure that can alternately be interpreted as a script loader or as an executable container

Yes, plus some other goodies.

Basically, PEs are recognized on Windows by the magic number in the first two bytes, which happens to be "MZ" (for good historical reasons) in ASCII. There are similar magic numbers for various binary executable formats used by many other OSes. (Claiming "any x86 OS" is clearly a little broad, because who knows how many people have implemented their own experimental OSes with crazy formats and conventions.)

Bourne shell scripts have to contain legal Bourne shell commands, but don't have to start with anything in particular, because when they were introduced the interpreter ("hash-bang") line concept hadn't been introduced.

So, when a POSIX OS is asked to execute a file, it sees if it starts with the magic number of any of the executable formats it knows how to run. If not, it has to try to run it as a Bourne shell script. (It can't really apply any heuristics except that if the first byte is binary 0, it can't be a valid Bourne shell script. Otherwise, in POSIX land, even a 2-byte file could be a valid script, because you can use any character other than NUL or / in a filename, and the script might just execute another file. But I digress.)

So, I can start a Bourne shell script with "MZ" and it looks like a PE to Windows. If I write that script carefully, I can actually make it both a valid Bourne script and a valid PE, because they're both pretty forgiving. In the case of APE, the script starts off by turning that MZ into the beginning of a variable name, as you can see if you follow the link in the article.

Then, if it's running as a PE, great; you just stick in the various PE sections after redirecting around the script stuff. If it's running as a script, it can do various things to get itself re-executed as the proper sort of file.

And then there's the web-app zip trick, which is one of the first tricks you learn when writing polyglots, and one that was used by Phil Karn's original PKZip (in the pksfx utility). A zip file has its metadata at the end, and the directory in the metadata contains offsets to the compressed contents. So anything can come before the zip data; decompressors will start at the end of the file and then jump into the middle of it. So you just take your executable and append the zip data to it, and you have both an executable and a zip archive.

I do this occasionally with a PNG image and a zip archive. The PNG image is of text that reads "This is a zip file. Rename it with a zip extension and open it again." It's handy for sending zips to people whose email clients block them, for example.