tptacek

This is still not as weird as the valley was in the late 1990s during the first Internet bubble, with the exception that housing scarcity, which was notably bad then (I had to pay my year's rent up front to secure an apartment in San Francisco), has been left to fester for 2 decades.

I love this. Anthropic employees just randomly have solutions to Smale's open problems in their back pockets, waiting for the right moment to sprinkle them into the training set.

Would you ordinarily be able to "explain this", if a mathematician had come up with this on their own? How would that story go?

Our auditor is Aprio.

I'm not going to, like, whip out my resume here, but I am going to confidently assert that if you structure your Type 1 carefully, you can trivialize your Type 2, and as someone currently operating a globally deployed public cloud I can tell you right now that SOC2 doesn't really touch on anything interesting in our engineering.

I wrote an article about this, and I think it's the Correct advice for virtually every startup thinking about SOC2:

https://fly.io/blog/soc2-the-screenshots-will-continue-until...

A few years before that, I wrote an article about what we learned from the consulting practice we ran building SOC2-supporting security programs for startups:

https://www.latacora.com/blog/2020/03/12/soc2-starting-seven...

I've had the experience, many times, of offering this advice in some forum and having someone try to rebut it, claiming that SOC2 is difficult, or that real customers will pick a SOC2 attestation apart with a fine-toothed comb looking for shortcuts you took, or that they built their whole security practice around SOC2. I can go all 12 rounds with someone on any of those points, but I think you can get most of my take from those two posts.

I think you can reasonably assume that frontier models are using SymPy or something like it any time interesting math gets into the picture, and the person driving Fable here is an accomplished mathematician, but I don't think we can reasonably assume either extensive prompting or brute-force compute in any sense other than what it normally takes Fable to, say, whip up a calculator app.

(Specifically: the SOC3 is a public report; the SOC2 report generally isn't supposed to be handed out except to named clients under contract. You pay extra to get the auditors to give you a report you can just stick on a website.)

A $50k audit is going to be team of 2 CPAs collecting evidence for 2 weeks.

Unless you have a very good reason (I compare notes with people at dozens of firms and have never heard one), the only criteria you ever want to get SOC2'd on is Security.

My experience is the opposite of yours: having a security SOC2 ends the vendorsec process it any enterprise buyer, and enterprise buyers virtually never read anything in the SOC2 other than a glance at the exceptions. A very large, very security-intensive vendor we have all heard of told me a story about a vendor they had that gave them several years of repeated Type 1 reports. Went fine.

Literally any firm can get a SOC2 Type 1, because there's no lookback to it; the Type 1 is a pinky swear.

In practice, if you're careful about how you do your Type 1, the Type 2 is almost as trivial. Your HR/bizops practice is much more likely to screw up and cause exceptions than anything you do in IT or engineering.

I co-ran a business with a significant SOC2 practice (we ran security programs for startups), and then oversaw Fly.io's SOC2 Type 2. The person you're responding to is more right than you are, and I would push back in a variety of ways on your point (2).

I wouldn't put it the way they did but they're directionally sane about this. I would worry a lot more about someone repping their SOC2 as important or meaningful than I would worry about someone who was cynical about SOC2.

(I don't mean Apple; Apple spends more on security than almost any firm in the world.)

https://fly.io/blog/soc2-the-screenshots-will-continue-until...

You can get a SOC2 done for mid to mid-high thousands.

Not really. The more expensive the auditor, the more they'll work with you to craft something that will avoid exceptions. There's no real "rigor" involved in SOC2! The "audit" here is in audit in the accounting sense: "do your records square up?". SOC2 auditors are generally not technical people.

It's hard to tell if you're being serious here. At the end of the day, Lavabit's security came down to... the FBI's inability to read an ultra tiny font?

That's not the actual story (like, that happened, but all it did was provoke the DOJ), but it's remarkable to see someone cite that as a success for Levison.

The introduction to this piece was easy to follow, but as soon as he got into recapitulating it with algebra he lost me (because I'm bad at math). But he includes the GPT5 prompts for his conversation, which are easier to follow:

https://chatgpt.com/share/6a5fdc7a-d6f8-83e8-bbea-8deb42cfed...

The model is very capable of checking this counterexample, was my point.

I don't understand why you're scare quoting "implicit search".

Depends on what you mean, but my subtext was that a lot of steganographic designs have turned out to be detectable; it's a design-level concern, where most consumer encryption problems are implementation issues.

Can you flesh that out? If I've missed something and oversimplified the design here, I'd want to clarify that!

We're talking about exactly the same threat. What I'm pointing out is that state adversaries won't have to "notice" this; all they'll have to do is plug the device into a standard commercial forensics scanner product --- and we're stipulating that they're plugging the device in already (else what does it matter what bits are on it).

They pay other people to notice this stuff for them!

We're both saying the same thing: you can make the KDF irrelevant if you (as you just specified) use an AES key as an input. The entire point of KDF is that humans don't do that.

Thanks! Per-seat licensing here checks out.

You can eliminate the problem entirely by using a random full-allowed-character-set password. The whole point of KDFs is that the password/passphrase is predictable (usually: by being generated from a seed dictionary).

The security track record of steganography is not great.

Can you check again and share where you're getting that number?

I'm generally pretty fatalistic about avoiding state-level adversaries. So, in a sense, it doesn't really matter how one thinks a security countermeasure is going to stack up against an IC attacker. The important thing is that people understand how hard this is to do, and take that into consideration before adopting tools like these. You can easily make things worse for yourself.

I think this post is a fun technical case study on its own. It only takes on urgency because it literally markets itself as a tool to slip past state adversaries. I think it's important that people understand that it isn't the state itself that's going to take the time to detect something like this; it's some commercial forensics vendor they use automatically.

This is 2 years old, but goes deep into the details of how the "0 click" market works, roughly what kind of money you'd be sitting on, and what it takes to actually get that money:

https://securitycryptographywhatever.com/2024/06/24/mdowd/

It sounds like you're telling me you believe you might get six figures for a "great" WordPress core RCE. I believe that's false, and I believe that for reasons that probably indicate our premises are much too far apart to hash this out here.

I have open contempt for online price list "brokers" like Zerodium. I do not have contempt for other commenters here. I think it's important that you understand the distinction before coming at me the way you've been in this thread. Disagreeing with me, rebutting or refuting me, sharply or ungenerously: totally fine. Your weird psychoanalysis of me: not fine.

This is self-soothing, not a real security plan. It doesn't matter how competent a security agency is, because there's a whole ecosystem of vendors selling into that space; knowledge of how to attack encrypted disks like this is outsourced, and, importantly, those firms have incentives to mop up even random stuff like this, because vendors will be selected in part based on lists of how many different circumvention and privacy tools they can detect.

If you're using off-the-shelf "hidden" encrypted volume schemes, you're not going to be evading state-level adversaries; if you can find these projects and conveniently use them, state vendors can and will write scanners that find them. They're paid to do it; new detections are how they get to charge for maintenance and new versions.

Then you're down to two issues:

(1) Concealing an encrypted volume jacks suspicion way up; whatever pickle you were going to be in if you just kept an encrypted DMG on your desktop, you're trebly in now.

(2) Your actual security comes down to the strength of the encrypted volume, and this is 20-year-old encryption. He can't use a memory-hard KDF because of his BOM, which, like, fair enough, but that doesn't change the fact that this KDF is probably ~50x faster than standard bcrypt hardness and on realistic human passwords is probably crackable in minutes-to-hours on a dedicated rig.

I winced particularly at the observation that the hardness was set where it is because of how long it takes to open the encrypted volume on this hardware, because whatever scheme is being used to run the KDF now, an attacker won't bother; they'll just copy the bits and attack them on serious hardware.

Point (1) isn't meaningful if your adversaries aren't states. It might make sense to have a hidden encrypted volume for the same reason you'd want an encrypted safe. But point (2) applies to everybody.