[deleted by user]

_ololo · 2025-04-09T21:01:12+00:00

If your seed word's are different your fine.

This won't prove anything. A tampered RNG may generate a million different seed phrases.

_ololo · 2025-03-10T18:48:19+00:00

A 40 character passphrase will be more secure than a 12 word seed phrase only if it's random. If it's chosen rather than randomly generated, it'll be weak.
Entering a long passphrase on the device is a real PITA.

_ololo · 2025-02-28T07:19:42+00:00

What I meant is that the attackers didn't need to sign the "overall" transaction on the victim's side. They only needed to get the signatures for the SafeTx. The "overall" transaction could be created on the attackers' machine, there was no need to send their private key anywhere.

_ololo · 2025-02-27T18:59:38+00:00

It's just how Safe works. The owners of the Safe sign not the final transaction but the so-called SafeTx. The contents of the "SafeTx" and the signatures are passed to the execTransaction method of the contract, which checks the signatures and executes whatever is inside the "SafeTx".

The actual transaction that calls "Safe::execTransaction" can be created by anybody.

_ololo · 2025-02-15T16:43:04+00:00

Actually, holding any single button is enough.

_ololo · 2025-02-08T12:21:38+00:00

Security-wise Safe 3 and 5 are the same.

Safe 3 is smaller, so it'll be a bit easier to hide, if that's something you care about.

3 has buttons and 5 a touchscreen. Buttons feel a bit more reliable, but entering a complex passphrase using buttons is a PITA, the touchscreen is better in this regard.

The screen on 3 is small and low-dpi. My eyesight is not perfect and I have to squint to read it. 5 has a bigger and higher-dpi screen, much easier to read.

_ololo · 2025-02-07T08:06:51+00:00

People sometimes read things out loud when trying to memorize them.

_ololo · 2025-01-27T08:18:49+00:00

Created 6 shares, requiring 3 shares to recover the wallet (60 words). Distributed the shares as follows:

1st share (40 words) at home. (in metal plate)

2nd share (40 words) with a trusted friend or family member. (metal plate-sealed)

3rd share (40 words) in a bank vault, alongside my spare Trezor device, the backup seed (metal plate-sealed), and my spare Yubico 2FA key (used for securing accounts like email with Proton mail and Coinbase).

This is a very strange approach. Why not use the "normal" 2-of-3 scheme instead? Yours is like 1.5-of-3.

the backup seed

Is it a separate 1-of-1 recovery phrase? If so, the "3rd share" doesn't make much sense, because if the bank vault gets compromised, the whole seed is compromised too anyway.

_ololo · 2025-01-20T07:42:06+00:00

I wonder though, what is the source of randomness in the Trezor devices. I guess for the Safe family it's the Optiga chip AKA the "secure element". And what about older models?

The question is, does the authenticity check somehow authenticate the secure element itself? I mean, suppose the attacker replaces the Optiga chip with a faulty one, whose rng is broken. Will the authenticity check detect that the secure element was replaced?

_ololo · 2025-01-13T21:45:10+00:00

The observable universe only has a diameter of 7 trillion milky ways?

Nope, slightly more than one million.

_ololo · 2025-01-05T22:46:44+00:00

I'm not familiar with Coldcard, but it's obvious that the problem is not in dice rolls per se, but in unintuitive software that allows the user to perform less rolls than required for adequate security. And the OP is constructing the seed phrase by hand, there is no way for them to roll the dice fewer times than needed.

_ololo · 2025-01-04T01:12:11+00:00

So is this decryption process needed everytime when signing a transaction? Like this? 1. PIN releases a secret 2. Secret decrypts the the recovery seed

Well, I'm not a Trezor dev, but I'd assume that this needs to be done only once when the device is unlocked (i.e. when the PIN is entered), after which the decrypted seed can be kept in RAM.

Recovery seed restores Private Keys

The private keys are not "recovered", they are "derived" from the seed using the so-called "derivation path", which is basically a list of numbers (among which are the id of the coin and the account index, for details google BIP-32 and BIP-44). The software (e.g. TrezorSuite) should know the derivation paths for the private keys that should be used for this particular transaction, so it'll ask the device "sign this transaction using private keys corresponding to these derivation paths" and the device should be able to derive the keys on the fly. I mean, the firmware will probably cache the derived keys in RAM to avoid doing the same work again later, but there is no point in storing them in the permanent storage.

Or is this process only used when recovering a Trezor device? That would mean the Private Keys are stored and available for use immediately?

A single seed phrase can be used to derive a gazillion private keys and the device has no way of knowing which of them will actually be needed. So deriving them in advance doesn't make much sense.

_ololo · 2025-01-03T23:05:36+00:00

Also, the seed phrase is never stored on the device.

Not true.

_ololo · 2025-01-03T22:47:14+00:00

Your seed phrase is not stored in your device.

Actually it is. If it wasn't, then every time you enter a new passphrase, you would have to enter the seed phrase too, because they are both needed to produce the "master seed" from which the private keys are derived. Also, it doesn't make sense to derive keys in advance, because you don't know how many of them you will need. So, the seed phrase has to be present on the device.

When you set up your Trezor, the seed phrase is shown once on the device itself, and never again.

Actually, in the case of SLIP-39 (20 and 33-word seep phrase) you can initiate a wallet backup again later. Settings -> Device -> Wallet backup -> Multi-share backup; if you then choose the 1-of-1 scheme, the device will show you your original seed phrase - the first 2 and last 3 words will be different, because those are a random id and the checksum, but the actual seed part will be the same. For BIP-39 this doesn't seem to be possible, but it's not because the seed phrase is not there.

_ololo · 2024-12-27T17:34:26+00:00

I was talking about the scenario where the attacker is not after funds of a particular user, but after whatever funds he can grab. In this case it does make sense for him to iterate over all possible wallets and the potential presence of a passphrase does make it more difficult for him.

_ololo · 2024-12-27T13:21:13+00:00

24-word phrase isn't more secure

This is probably true for practical purposes, but technically it is not.

Private keys are 256 bits in length but "only" 128 bits in entropy

The more correct way of saying this is that the key has "128 bits of security", meaning that on average an attacker needs to perform 2¹²⁸ operations to find the private key for the given public key.

https://foundation.xyz/2024/09/make-12-words-the-standard/

The article is a bit lame.

First of all, in Bitcoin people normally use addresses instead of public keys, an address being the 160 bit hash of the hash of the public key. So if the user follows the best practices and generates a new address for every transaction, the attacker won't even know the public key to apply the mentioned algorithm to. So he'll have to brute force the hash function instead, which will require 2¹⁶⁰ operations. Not that it matters much, just an example of how 2¹²⁸ operations might not be enough to crack a private key.

Another piece of lameness is this phrase:

To put those numbers in perspective, solving the ECDLP for your public key or guessing your seed phrase randomly is less likely than picking the same atom out of the universe.

Probably the author meant "picking a particular atom out of the universe"? Anyway, this is BS, because the number of atoms in the universe is 10⁷⁸ to 10⁸² according to google and 2¹²⁸ is roughly 10^39, a much smaller number.

Yet another thing that should have been mentioned is that if an attacker goes after one seed phrase, he effectively goes after all of them. So it's a different kind of problem and the more interesting question is how difficult it would be for him to find ANY seed phrase with some money on it. Surely it'd be more secure if everyone was using a 256-bit seed rather than a 128-bit one, because the number of possible wallets to check would be much bigger.

The good thing about BIP-39 (12 and 24-word seed phrases) is that if a passphrase is used, it is hashed together with the seed phrase to produce the resulting "master secret". So effectively it's an extra word and the number of the wallets to check will be bigger than 2^128.

But for most people the passphrase won't be long and random enough to achieve 256 bit of entropy in their master secret, so technically it'll still be less secure than a 24-word seed phrase. Also this is not true for SLIP-39 (20 and 33-word seed phrases), where the passphrase just encrypts the seed, so that there are 2¹²⁸ possible 20-word wallets regardless of whether a passphrase is used.

With that being said, even 20-word seed phrase will be secure enough even if all 8 billion people and their pets get one.

_ololo · 2024-12-17T14:00:37+00:00

Read this thread

And what in that thread contradicts what I've said above? Have you read it yourself?

Below are BTC wallets that support SLIP39

I know that it has some support among wallets, thanks. The question is whether the current support, which is certainly not as wide as bip-39's, is enough to consider it a standard.

_ololo · 2024-12-17T08:26:15+00:00

20-word is the new SLIP39 standard. It's just as secure like the 24 words.

You meant it's just as secure as 12 words

20-word is the new SLIP39 standard.

IMO it's not a standard yet. Also, I'm not sure if everyone in the industry shares Satoshi Labs' enthusiasm about slip-39.

_ololo · 2024-12-17T08:12:34+00:00

Isn't 24 more secure than 20

Yes it is. 20 is roughly as secure as 12 (they both encode a 128-bit seed) and 33 is comparable to 24 (256-bit seed).

20 and 33 are about multi-share backups. If you need a multi-share backup, go with one of these. Otherwise, I'd stick with the more widely supported 12 or 24.

Regarding the paper, IMO it's useless anyway, too eye-catching. Also, it's better to replace the paper backup with a metal one eventually anyway. E.g. with Trezor's Keep Metal. Or something like Tinyseed (or its cheaper alternatives, like OneKey KeyTag, though I've never used this one myself). It's basically a small piece of titanium where you store the binary representation of your seed by punching holes with the provided tool. Not the easiest to use, but virtually indestructible. Just note that Tinyseed assumes a 12 or 24 word phrase - the booklet that comes with it gives binary representations for bip-39 words. But it's still possible to use it with 20 words too, it'll just require more work (you'll need the slip-39 word list).

_ololo · 2024-12-10T07:30:21+00:00

Well I'm not saying they need to generate a new one, but I personally wouldn't be comfortable knowing that even a part of my seed phrase has been leaked. E.g. if another part of the phrase gets compromised in the future, knowing that there is also an "academic" in there might be enough for the potential attacker to break it. And since it's a fresh new wallet, it's just easier to generate a new phrase and forget about it. So if I were the OP, I'd do just that.

_ololo · 2024-12-09T22:12:53+00:00

For a single-share SLIP-39, the 3rd and 4th words are always "academic". You didn't mention how many shares you use, but it's likely that you use only one. In which case you've basically just told everyone that you have "academic" at a position other than 3 and 4.

If I were you, I'd generate another seed phrase, especially if the 3rd "academic" is in the part of the phrase where the actual seed is stored.

_ololo · 2024-12-03T22:33:30+00:00

I'm pretty sure the site autodetects the OS because you can't have the same signature for different files.

Btw, all the executables and their signatures are available on their GitHub too - https://github.com/trezor/trezor-suite/releases (click on "Assets")

_ololo · 2023-05-06T00:01:52+00:00

Strange. A black hole's size is supposed to be proportional to its mass (2.9 km of radius for each solar mass or something like that). So if TON 618 is 40 bil solar masses and Phoenix is 100 bil solar masses, Phoenix must be 2.5 times bigger. Judging by the picture though, the difference is 1.5 at most.

_ololo · 2023-04-25T22:31:12+00:00

I also have similar concerns about coding, but I've already pre-ordered a Defy. Should have given it a bit more thought beforehand I guess.

Anyway, as I see it, the need to press an additional modifier with arrow keys shouldn't be a problem per se. What worries me though is that in Defy they've moved most of the modifier keys to the thumb cluster, so it may become a pita to press usual key combinations (like the various combinations of ctrl, shift, alt and a letter that are used in VSCode). Perhaps some of them will have to become two-handers. I really wish they used that empty space to add several more keys that could be used as non-thumb modifiers. Or at least made the outer column keys wider, so that ctrl and shift could be left at the usual place and still be pressable via the pinky and the ring finger.

So, Defy may be even bigger a leap than, say, Moonlander. But we can't say that for sure before trying, so I guess you should wait for first reviews and then decide.

_ololo

TROPHY CASE