sha256 is safe from quantum computers
secp256k1 is not
No, I specifically said “only pushes one without mentioning others as much” and “bashes other options and alternatives to those”
Just think about the top podcasts.
Which of them are influenced by people with bags VC funds like Ten31?
Do they constantly push a certain HWW vendor and not others?
Do they bash projects like nostr:npub17tyke9lkgxd98ruyeul6wt3pj3s9uxzgp9hxu5tsenjmweue6sqq4y3mgl with false claims?
And so on.
The problem with HWWs is that the overlap between people that know or learn how to write secure software and best practices, and those who make a HWW, is small.
The industry is rotten to the core with a lot of podcasts being paid off to FUD competitors or alternative solutions that don’t pump their VC bags.
They don’t care about money. They care about selling you a cheap product for a lot even if it means cutting big corners in security.
“When we told our developers about our plans to do a certification, they disappeared into the server room and didn't come out! We think they're hiding under the floor, is there anyone who can help?”
I can confidently say that the HWW space is being ran by 95% clowns.
If you exclude the wallets that are not bitcoin only, that becomes 100%. nostr:note1upvg0s73kj57387rpq3zq55jm29fsrf838vnps79k3zzk3ypaldshhpnft
Your following list got wiped(?)
Look at:
- ST32 from STmicro
- TEGRION series from Infineon
- SmartMX3 from NXP
The SE050 is just a configuration of the P71D321 in a chip form factor with JCOP and an applet
Yes, MCU side.
We cannot audit the MCU because there’s code protection measures unless you were to have equipment to do a fault attack on it, and this needs to apply to every user.
A good change.
But far from ready. Security ICs take years to develop and perfect.
And in the end, you still cannot verify code running on it, the only difference being NDAd documentation and architecture which makes little difference to the end user.
the goals of security and verifiability are inherently conflicting as to verify you need a chip that anyone can check the content of, but for security you want a chip that no one can see the content of
the MCU may have open source code but the moment it is compromised it could log your PIN on next attempt
My take - the take I had adopted for nostr:npub1j9kttlc86w63emmldd4h74rekyqpksqup6p9trhp5gjsf374qlyszvuswx - is that a "secure element" does not get in the way of verifiability iff it does never handle the private key material. It may contribute "true randomness" and it can be used for a key encryption key but the parts that actually touch the keys must be public source and binaries reproducible and the device itself has to show the actual hash of the binary you are trying to install prior to installation.
still, a pointless attempt.
coldcard for example has a dedicated privileged flash segment (the “boot ROM” which is not ROM at all) that handles retrieving the key and could store the PIN/root key in its small flash segment
it is not truly verifiable without ripping out the chip and faulting it
both of those are not a good fix for public relays, but they are needed
and false “verifiability” in HWWs, as their designs also mean it makes verification impossible (SE code) or requiring somewhat costly tools to work around security measures (MCU)
having NDAd secure elements is arguably better for security than “verifiability” as in both cases the manufacturer could slide in a backdoor but one means you usually end up opting for worse parts
doing something you are unfamiliar with is fine
but when it comes to securing millions in funds… you need to do research. and be honest where you fall short
too much time is wasted on marketing and the likes: eye candy over functionality, security taking a backseat (“resolved” by adding one or two IoT SEs with a lower bar for security compared to even a credit card, made by manufacturers that do not have a track record for high security SEs) and exaggerated marketing claims (“most secure”, “only airgapped wallet”)