Thomas Ptacek, a security and cryptography practitioner, writes about DNSSEC, cryptography engineering, random number generation, and hiring.
HN commenters cite his arguments against DNSSEC and treat his cryptography writing as a reference, and he is also linked for his hiring post.
"More efficient" of course has many axes (cost, energy consumption, manual labor requirement vs cost of human, time, quality, etc.). However, as a long-time reverse engineer and exploit developer who has worked in the field professionally, I would say LLMs are now useful; their utility exceeds that which was previously available. That is, LLM assisted exploit discovery and especially development is faster, more efficient, and ultimately cheaper than non-LLM assisted processes.
What commenters don't seem to understand is that especially CVE spam / bug bounty type vulnerability research has always been an exercise in sifting through useless findings and hallucinations, and LLMs, used well, are great at reducing this burden.
Previously, a lot of "baseline" / bottom tier research consisted of "run fuzzers or pentest tools against a product; if you're a bottom feeder just stuff these vulns all into the submission box, if you're more legit, tediously try to figure out which ones are reachable." LLMs with a test harness do an _amazing_ job at reducing this tedium; in the memory safety space "read across 50 files to figure out if this UAF might be reachable" or in the web space, "follow this unsanitized string variable to see if it can be accessed by the user" are tasks that LLMs with a harness are awesome. The current models are also about 50% there at "make a chain for this CVE," depending on the shape of the CVE (they usually get close given a good test harness).
It seems that…
Uh, this is also dangerous to your security. The truecrypt docs contain very large warnings about this[1]: someone who can see your disk at multiple versions may be able to drastically weaken your security. If you had keys in those truecrypt files, you should rotate them; if you had secrets, consider them compromised.
Truecrypt uses XTS mode, which is Not Great -- it only exists because someone was trying to hammer ciphers into fitting nicely with fixed sized disk sectors, and it makes a number of serious compromises to do so. [2] has a good discussion of this. You do not want to combine XTS with sharing multiple versions of the ciphertext.
tl;dr you've seen the penguin pictures? As [2] cleverly says, you're pretty much doing that to yourself by sharing multiple versions of the file.
There's also significantly more powerful attacks that can be mounted by an adversary that can feed you corrupted blocks which will allow them to permanently compromise your key, or perform other hijinks like manipulating your content without setting off warning bells. Dropbox, or someone that compromises dropbox, is in that position, by nature of the service they're providing. These issues are rooted in the fact that XTS is not an authenticated cipher -- this leads to such an endemic category of subtle problems that it's been nicknamed "The Cryptographic Doom Principle" [3].
So yeah. If your life depends on it... don't store a truecrypt volume in dropbox.
-----
[1] I found a mirror…
It looks like there is a trend starting in the software industry to encourage empirical hiring. This particular article follows about a month after another hiring post reached the front page of HN.[1]
I really agree with it, and I hope more people are looking at it seriously instead of fixating on the fact that the word "Google" is in the title. Giving all the candidates the same questions and the same exact interview methodology is much more fair and empirical than simply having an interviewer wing it (which is virtually certain to bring in bias). Most interviewers I know think they are better than the average interviewer due to illusory superiority cognitive bias [2]. However, when it comes down to it, you cannot easily judge the difference between candidates if you ask one a completely different question than another. This goes against all the principles of psychometric testing, yet it is still ubiquitous because no one has bothered to empirically look at whether or not they're really interviewing in a rigorous way.
There is a serious issue in the industry right now where otherwise capable people fail interviews due to their appearance, manners of speaking or other harmless idiosyncrasies. It's because interviewers are very personally attached to their subjective methods, and they tend to really enjoy having personal ownership over the interviewing process instead of surrendering control to a standardized script. This trend looks like the software hiring equivalent of a…
Right, I think we're probably in agreement on a lot too. I do think if you're looking for a specific thing (whether it's a code monkey, or a visionary, or someone that seems to have the potential to grow into someone amazing, or a Postgres expert who can help you solve your particular scaling issues right now and then go away) you should try and purpose your interviews for figuring out whether those things are present to sufficient degree, and ignore/deprioritize getting data on other things. Though I also think even with the large variety of roles that exist, they all need an ability to program and solve the types of problems that the business is working on and is likely to encounter, so this should be tested/verified as early as possible, and that a lot of people are fooling themselves in thinking they need much more than that or that the other things they claim to care about actually matter.
Consulting gigs (like the postgres expert) avoid a lot of the crazy interview nonsense, and a large part of that I think is that wanting to trade services for money is more than enough, but sure their limited tenure is another big factor and helps them from needing to buy into the company culture or whatever. But this precludes that the business knows what services they want to receive in exchange for money. And repeating myself, often businesses aren't even sure, or don't actually need much more beyond "can program competently for our use cases" (which doesn't mean code monkey). So…
Author here: you're right, nothing revolutionary here in technique. Most/all of our actual process is ripped straight out of http://sockpuppet.org/blog/2015/03/06/the-hiring-post/. But my experience, over the course of Spreedly interacting with 100+ candidates over the past few years, is that just doing pretty standard things well, with attention to detail, is in itself revolutionary. We hear story after story from candidates about other companies they have or are interviewing at that are completely disrespectful in how they're treating candidates. Whether this is cargo culting, lack of time to do things right, or a righteous belief that it's OK to treat candidates poorly, I can't say, but it's pretty disgraceful.
So, I wrote this little thing both since I needed to write it down for my coworkers anyhow - this is how we do things, showing respect for candidates by keeping reciprocity, incrementalism, and relevance in view - but also in the hopes that it's one more brick in a wall of "you're worthy of respect" for candidates.
The post itself wasn't about our actual process, though I did use examples from it; I hope to write about the actual process later. But I will note that my experience of phone screens is apparently very different from yours: I've experience them as a chance to pre-grill and filter candidates, and ours is 100% not that. I ask zero questions, but instead just talk about what we do and answer any and all questions candidates have. You're right that doing…
It's complicated. For starters, if you're looking for a _secure_ PRNG most practitioners would strongly advise _against_ the system you described[1]. There's a difference between a cryptographically secure algorithm and a secure system. For the overall system to be secure you need to make sure the seed data is secured, which you're bound to fail at unless you really know what you're doing.
Providing a "cryptographically secure but not really secure" alternative implemented in user space alongside a "really secure" alternative that's been thoroughly vetted would likely just add to the confusion. If you _really_ need secure numbers you should be using the really secure one. The really secure one is almost definitely going to require a syscall worth of overhead, at least, so it's _definitely_ going to be slower than a PRNG like xorshift128+ which literally takes a single digit number of CPU cycles.
Now to answer your question, if you're just talking about a CSPRNG algorithm they're probably fast enough for almost every use case. I think there's still an argument for some things like array shuffling, but those implementations could go out of their way to use the non-CS algorithm as an optimization. Unfortunately in Javascript land there's aren't many batteries included, so if you switched Math.random() to use a CSPRNG most people would end up using it for trivial stuff like shuffling arrays. If you're talking about a secure system... it's probably still fast enough for most…