[ruthmarx]

> I've never seen anything like that and don't believe it's practical. 3D-printed patterns will not look the same.

I'm not talking about 3d printers specifically, just high precision printers. It's absolutely practical.

> This entirely depends on your threat model and how much you suspect a tampering at specific conditions.

I was talking about you personally, who I assume is a pretty average developer that doesn't have state actors after them.

> What is simpler depends on the threat model and a person.

No, it doesn't. This screws method you describe is inferior for all threat models and persons. It's basically security theater.

> For me, Secureboot is not a better method anyway.

You might not prefer it, but it is objectively a superior method.

[fsflover]

> just high precision printers

2D printers just won't cut it: https://i.pinimg.com/originals/90/7a/2e/907a2ece23d412d28b66...

https://3.bp.blogspot.com/_BkvigWu1n1A/S8YrMyV_kTI/AAAAAAAAB...

(and so on)

> I was talking about you personally, who I assume is a pretty average developer that doesn't have state actors after them.

This is why I wrote below about eventual discovery of a possible tampering and low priority of checking it in principle.

> This screws method you describe is inferior for all threat models and persons. It's basically security theater.

This is a strong claim without any evidence. You didn't show how to overcome it.

> You might not prefer it, but it is objectively a superior method.

It isn't: https://forum.qubes-os.org/t/discussion-on-purism/2627/187, and https://forum.qubes-os.org/t/discussion-on-purism/2627/158, and https://news.ycombinator.com/item?id=41072929, and https://news.ycombinator.com/item?id=41071708, and https://news.ycombinator.com/item?id=35843566

[ruthmarx]

> 2D printers just won't cut it:

Not your off the shelf consumer stuff, no, but there are printers that could do it, for sure.

What's more, I really have no idea what the point you are trying to make by linking those images is showing. Printing designs on nails doesn't require the level of resolution your screws idea would, so it isn't really relevant.

A quick search shows an especially high resolution 3d printer released last year in May, that can print at a 20-nanometer resolution, the D4200S[1]. That's basically cutting edge, and way, way overkill to print at the resolution required to fool you after tampering with your device.

> This is why I wrote below about eventual discovery of a possible tampering and low priority of checking it in principle.

It's a given that how often someone would check something like that (not that it would be used in practice) depends on their threat model, but you used yourself in the example originally. The point was you wouldn't be doing this, and in the context of the original comments and conversation it didn't make sense as a suggestion.

> This is a strong claim without any evidence. You didn't show how to overcome it.

The problem here is your assumption that the screws are not easy to reproduce, except they are. It's a false assumption. I showed capable printers exist, in addition exist the level of precision the worlds best counterfeiters can work at and are capable of, and yes, state actors have access to such people.

> It isn't:

It absolutely is.

All your arguments, or the links you gave that imply the arguments you didn't make, are limited to using preexisting keys which is not a requirement, or existing flawed implementations, which are not a requirement. Secureboot is a standard, and you are free to use your own keys, and own implementation - if you can't write or manufacturer your own, there are still open solutions you can trust like those from pureism, and software like coreboot.

It would really be better if you make an actual argument and reference urls rather than just spamming a bunch of links FYI. I shouldn't have to open 10 tabs to understand your reasoning.

[1] https://3dprinting.com/news/nano3dprint-launches-highest-res...

[fsflover]

> 3d printer released last year in May, that can print at a 20-nanometer resolution, the D4200S[1]

This is impressive indeed. I agree that if you expect that your adversary spends this much resources on you, nail polish wont' be sufficient.

> Secureboot is a standard, and you are free to use your own keys, and own implementation

Show me a FLOSS implementation of this standard and you will have a point. At the moment, I would have to trust a megacorporation obeying NSA, so I don't see it as a good defense against real adversaries. Your threat model may vary.

[ruthmarx]

> Show me a FLOSS implementation of this standard and you will have a point

I've had a point from my first comment and it hasn't changed in validity. It's just taking time to convince you, but I think I'm making progress :)

I referenced several open implementations in my last reply, an a cursory search reveals more [1] [2]. Besides, this still doesn't help you trust the hardware, even if that hardware is entirely open like some sort of RISC chip. Can you verify every step in the supply chain? At every stage of assembly? No? Or, assuming a trusted device, can you be 100% confident something wasn't added, a simple keylogger? Most keyboards can be removed from laptops without leaving a trace, so can screen casings, speakers, batteries, etc. Plenty of places to hide something tiny.

> At the moment, I would have to trust a megacorporation obeying NSA,

That's less likely than the software you use having been compromised, for example by introducing an obfuscated bug, or MitMing as you perform a software update (many software update mechanisms have notoriously weak security, search some defcon talks on the subject).

> Your threat model may vary.

No, what I'm saying applies to all threat models, and I challenge you to name one to disprove that.

Secure boot is an open standard and can be implemented in a trustworthy and secure way, you just need to put in the work to do so. It's entirely possible to do so.

Of course if you are putting in all that work, if you are that at risk, you would need to switch your software stack entirely as well and use something like seL4 as a starting point.

[1] https://github.com/prplfoundation/prpl-secure-boot

[2] https://www.coreboot.org/