undefined | Better HN

0 pointsDSingularity1y ago0 comments

I don’t think you are thinking of this right. One bit of leakage makes it half as hard to break encryption via brute force. It’s a serious problem. The defaults are justified.

I think things will only shift once we have systems they ship with fully sandboxes that are minimally optimized and fully isolated. Until then we are forced to assume the worst.

0 comments

jorvi1y ago

> I don’t think you are thinking of this right. One bit of leakage makes it half as hard to break encryption via brute force.

The problem is that you need to execute on the system, then need to know which application you’re targeting, then figure out the timings, and even then you’re not certain you are getting the bits you want.

Enabling mitigations For servers? Sure. Cloud servers? Definitely. High profile targets? Go for it.

The current defaults are like foisting iOS its “Lockdown Mode” on all users by default and then expecting them to figure out how to turn it off, except you have to do it by connecting it to your Mac/PC and punching in a bunch of terminal commands.

Then again, almost all kernel settings are server-optimal (and even then, 90s server optimal). There should honestly should be some serious effort to modernize the defaults for reasonably modern servers, and then also have a separate kernel for desktops (akin to CachyOS, just more upstream).

DSingularityOP1y ago

Maybe so but I think most users are going to be vulnerable to likely under-estimate their security-sensitivity than to over-estimate. On top of that security profiles can change and perhaps people won’t remember to update their settings to meet their current security needs.

These defaults are needed and if the loss is so massive we should be willing to embrace less programmable but more secure options.

j / k navigate · click thread line to collapse