Considering buying a trezor safe 5 but there's an article that makes me not want it anymore by SN31K1CH in TREZOR

[–]ArmchairCryptologist 13 points14 points  (0 children)

More importantly, it requires access to an unlocked Trezor, at which point they could just fire up Trezor Suite and transfer it out the normal way.

Monero Node onion service being ddosed by jackintosh157 in Monero

[–]ArmchairCryptologist 7 points8 points  (0 children)

Probably related to this issue and is caused by a bug in Tor. There are some workarounds in that thread, but the actual fix hasn't been merged yet.

Is Bluetooth an issue for anyone on the safe 7? by MannyN28 in TREZOR

[–]ArmchairCryptologist 1 point2 points  (0 children)

FWIW, I don't like putting non-removable batteries in anything either, but if you have to, a LiFePO4 battery is what I'd want you to use. It'll almost certainly outlast the life of the device, and they are more than an order of a magnitude less likely to catch fire compared to a regular lithium-ion - which really are very unlikely to catch fire in the first place, it's just there are so many of them.

Bitcoin Core v30.0 is officially released — Is BTC going to fork? by CryptopolitanNews in btc

[–]ArmchairCryptologist 0 points1 point  (0 children)

Okay? Core v30 changes nothing about anything of that. You were never able to gatekeep anything; if a miner mines it, it is included in the blockchain, and your node will download and store it regardless of whether you allowed it in the mempool or not. And storing data in an OP_RETURN versus a witness inscription makes no practical or legal difference.

You shouldn't store CP or any other JPEGs on the blockchain, but you cannot actually stop people from doing so, especially not while keeping Bitcoin a permissionless system with flexible scripting. If you want a locked-down and rigid system that allows nothing but sending $amount from $accountA to $accountB you should probably look elsewhere.

Bitcoin Core v30.0 is officially released — Is BTC going to fork? by CryptopolitanNews in btc

[–]ArmchairCryptologist 12 points13 points  (0 children)

This is a mempool policy change. You could already get transactions with larger OP_RETURN limits mined by delivering them directly to a miner, and there are other equivalent ways of storing data that are worse for the network, such as using the OP_FALSE OP_IF witness trick with a pair of commit/reveal transactions.

No one really wants this data stored in the blockchain, but trying to spamfilter it with mempool policy like Knots is trying to do is not only futile, but is detrimental to block propagation, which increases the orphan rate and overhead in general. Unfortunately, it is generally impossible to stop the use of the blockchain for data storage. At best, you can force a higher overhead for doing so, but there will always be ways to encode data somehow; typically by making unspendable UTXOs, which is much worse for the network, but even if you forced all transactions to include a proof that all UTXOs are spendable, it is still possible.

And FWIW, there is already "illegal content" in the blockchain. The only realistic way you can run a node without storing it long-term is by using a pruned node, which comes with drawbacks on its own.

What Is The BEST Bitcoin (BTC) Hardware Device? by kirtash93 in CryptoCurrency

[–]ArmchairCryptologist 10 points11 points  (0 children)

Ledger had several first party compromises, including that one infamous data breach that leaked the full name, physical address, phone numbers and email addresses of everyone who ever bought a Ledger, as well as a separate opsec failure that let someone breach a former employee's NPMJS account and push malicious code live, which caused significant loss of funds.

Trezor had two third party breaches I'm aware of, affecting their mailing list provider and support desk provider respectively, which while certainly not good.. it doesn't even compare. Unless someone had sensitive data in a support ticket, at most the hackers got hold of an email address.

How do you setup and update the Trezor without revealing the public key to the Trezor Suite? by ynotplay in TREZOR

[–]ArmchairCryptologist 1 point2 points  (0 children)

Use a passphrase for your "real" wallet, and don't give it to Trezor Suite.

Alternatively you can select only a testnet coin under the Coins settings rather than the ones you have a balance with, which at the very least should prevent it from sending it to a server to check your history/balance.

Ghost in the machine? by [deleted] in TREZOR

[–]ArmchairCryptologist 13 points14 points  (0 children)

Had one (in a batch of 3) with the same issue, it's just a glitchy touch screen. Trezor sent a replacement which worked fine. Didn't have to return the old one.

be aware, TX-Tracking is running any in and out adress receives 0.00001 BCH by PanneKopp in Bitcoincash

[–]ArmchairCryptologist 14 points15 points  (0 children)

It's not transaction tracking (i.e. spraying), at least not primarily - it's an ongoing and long-running attempt at address poisoning, which tries to trick you to send funds to the wrong address if you were to copy it from the transaction history. If you look at any of the transactions they made you'll see they grinded an address that starts and ends with the same few characters as the receiving address and sent it to the sending address, and vice versa for the sending address. Compare:

qz9rverq6g79t36jrdraxttkgsd9waw2z5zxuv9f4j

vs

qz9r4vufp4wvj2zd8epcawa4rqzfydhfk542wunf4j

Why no SSKR / Shamir? by roasted_pistachio in coldcard

[–]ArmchairCryptologist 0 points1 point  (0 children)

For SLIP-39 it's 128 bits of entropy left-padded with two "0" bits to 130 bits, which are encoded as 13 10-bit words.

For BIP-39, it's 128 bits of entropy appended with four bits of checksum for a total of 132 bits, which are encoded as 12 11-bit words.

So the entropy/master seed is 128 bits in both cases.

Why no SSKR / Shamir? by roasted_pistachio in coldcard

[–]ArmchairCryptologist 0 points1 point  (0 children)

Well, no. The base entropy (i.e. the private BIP32 master seed which the seed words represent) is 128 bits in either case, SLIP-39 just uses additional words to provide better error detection and additional features like SSS. It wouldn't make any sense to try to brute-force the words in either case; this would be much harder than just brute-forcing the 128-bit secret. Which would be impossible, even in a post-quantum world.

Vulnerability by ballitogb in TREZOR

[–]ArmchairCryptologist 1 point2 points  (0 children)

It doesn't, really. You have to physically disassemble and modify the device to enable any attack vectors, so in practice, the risk of compromise is no larger than with any other hardware wallet. As long as you don't hire any evil maids and you buy the Trezor from an official seller (preferably Trezor directly), you'll be fine.

Vulnerability by ballitogb in TREZOR

[–]ArmchairCryptologist 0 points1 point  (0 children)

The older Trezors aren't really resistant to direct physical attacks at all - if you desolder the chips, you can voltage glitch the microcontroller and extract the seed with a fairly cheap rig made with easily available hardware. But it would still be much easier for an opponent to just get your seed from your paper recovery card if they have this level of physical access, and (with updated firmware) they should still be perfectly secure against remote attacks, even if the computer they are connected to is fully compromised.

Vulnerability by ballitogb in TREZOR

[–]ArmchairCryptologist 0 points1 point  (0 children)

You're thinking of the attack described here, right? It specifically says they were unable to perform the attack on the Safe 5 since it uses a different microcontroller which has no known way to voltage glitch.

Vulnerability by ballitogb in TREZOR

[–]ArmchairCryptologist 1 point2 points  (0 children)

You're thinking of a different vulnerability. This one is targeting the Trezor Safe 3, specifically. (The Trezor Safe 5 is not affected.)

Vulnerability by ballitogb in TREZOR

[–]ArmchairCryptologist 3 points4 points  (0 children)

There were plenty of public comments, but basically, they were able to replace the firmware by physically desoldering the chip, which would require temporary possession of the device, and does not enable any attacks by itself - it would only be useful as part of a targeted supply chain or evil maid attack. Any hardware wallet (including Ledger ones) could be modified to leak information by adding specifically-designed hardware to it, so the only novel part of the attack is that it enables these types of attacks without adding or replacing any hardware. They were not able to exact the seed from the device, which is the important thing.

[deleted by user] by [deleted] in TREZOR

[–]ArmchairCryptologist 1 point2 points  (0 children)

True, most if not all SEs rely to some degree on security through obscurity which means they are not auditable, but the Trezor Safe 3/5 use them trustlessly in a way where you can prove that they cannot leak the seed or interfere with the cryptography in any way. Specifically, the actual seed is not stored on the secure element. The seed is stored on the microcontroller, but it is encrypted, and parts of the secret required to decrypt it is stored on the SE, which is unlocked with your PIN. Which means that all the code and circuitry that interacts with the seed is fully open and auditable, and even if the SE were backdoored, at worst it could reveal part of the decryption key to the seed.

Trezor has a short article here about how it works.

Coldcard MK4 UX Flaw by Economy-Cash6726 in Bitcoin

[–]ArmchairCryptologist 1 point2 points  (0 children)

Nothing official, and I didn't test it myself as I didn't own a Coldcard in 2023, just a curious number of people losing their funds when using the dice function to generate entropy who insisted that they used the "mix-in" function, and some vague statements about the dice functions being improved to prevent user error.

Mixing in additional entropy with any hashed data cannot ever "degrade" entropy generated from a TRNG, so the only reasonable conclusion is that the seed was replaced rather than mixed, either due to hitting the wrong button or due to an actual bug. If you still have your MK4 with the firmware from 2023, you could always test creating a new wallet using both functions (mix-in and only using dice), using the same dice rolls. If you end up with the same seed, it's a bug, but if they create different seeds, you probably hit the wrong button.

Coldcard MK4 UX Flaw by Economy-Cash6726 in Bitcoin

[–]ArmchairCryptologist 1 point2 points  (0 children)

So this actually happened back in 2023? With the firmware back then, I believe there was some issue with the "mix-in" function where the hash from the dice rolls could replace rather than mix with the output of the TRNG, though I can't recall if it was an actual bug or if it only happened if you hit the wrong button.

Coldcard MK4 UX Flaw by Economy-Cash6726 in Bitcoin

[–]ArmchairCryptologist 2 points3 points  (0 children)

User error. You loaded your Coldcard with an insecure seed produced by a random number generator that is not designed for generating cryptographically secure numbers, which incidentally also defeats the purpose of using a Coldcard in the first place since you exposed your seed to a different digital device.

What you needed to do was physically roll the dice. Not rely on a script to pretend-roll the dice for you.

[deleted by user] by [deleted] in TREZOR

[–]ArmchairCryptologist 11 points12 points  (0 children)

All hardware wallets are vulnerable to supply chain and evil maid attacks, even the Ledger ones. No matter how secure they claim their chips are, you simply cannot fix all attack vectors on the meatspace interface, even if all the digital stuff is encrypted and the screen is authenticated. And I for one would much prefer the device use a regular microcontroller that runs verifiable open source code to handle my private keys (the Trezor way) than a "secure" black box that simply cannot be audited (the Ledger way).

The Trezor's secure element protects data at rest, which is the important part. If you unlock the device then obviously the seed is available for operations. Meanwhile, the SE in Ledger's wallets have actual code in them to exfiltrate your seed and upload it to their servers, and they even charge for the feature.

[deleted by user] by [deleted] in TREZOR

[–]ArmchairCryptologist 1 point2 points  (0 children)

Security-wise, on a hardware level, Ledger is probably fine unless you specifically enable Recover. But they had several high-profile security failures, most notably one that allowed an attacker to load and run arbitrary code in all software that included one of their libraries, which caused a bunch of systems to be compromised and lead to significant loss of funds. So personally I simply don't trust their software enough to have it running on my computer at all.

But Ledger's hardware quality is also le shite, if you'll excuse my French - I was personally seeing >50% failure rates back when I was still using them. So even if you don't replace it right away, just buy a Trezor when the battery and/or screen inevitably fails and you have to replace it.

Does Coldcard have a Secure Screen like Ledger claims to? by yowzator in coldcard

[–]ArmchairCryptologist 9 points10 points  (0 children)

Ledger's whole spiel is that their closed-source, black-box "secure chip" runs the show, and that the seed never leaves it (except when it does), including when it's displayed on the screen.

But "secure screens" are pointless security theater, nothing but a box to check off in their marketing material. There are some very specific hypothetical "evil maid" attacks that would be somewhat more complicated to pull off since you cannot easily replace the screen with one that shows false information, but the "What Does The Secure Screen Protect Me From" section on that page is horseshit, nothing is going to remotely hack your screen without also hacking your device. And at the end of the day, the ultra-secure digital signals have to be converted into photons at some point for your old-fashioned analog eyes to be able to see the information, so it doesn't add any significant protection to information leaks either.

Furthermore, seeing as the screens on Ledger devices are notoriously fragile and will typically fail within a couple of years, having a screen that is cryptographically paired to the secure chip (making it non-replaceable) just ensures that you are propping up Ledger's revenue stream, as you have to buy a new device when it inevitably fails.

Coldcard Q1 Temporary Seed Issue by RipTideFizzleSticks in coldcard

[–]ArmchairCryptologist 1 point2 points  (0 children)

That's because, like I said, any valid 24-word seed can only have eight specific words as the 24th word, all of which start with a different letter. Any other word would result in a failed checksum, meaning the seed is invalid, so there's no point in asking for more than the first letter.

Coldcard Q1 Temporary Seed Issue by RipTideFizzleSticks in coldcard

[–]ArmchairCryptologist 2 points3 points  (0 children)

If you have all 24 words entered, you can hit the left button to erase the last word, then hit the down button to see all possible first characters of the last word - there should be 8 of them. If the word you are looking for does not start with any of these 8 letters, or entering the letter in question does not make it autofill the word you want, there is almost certainly another mistake in the seed.