@Trezor @RockyPsionics @tobi_salami_ Would it be possible to add an optimized BIP39 wordlist entry mode for passphrases (like Jade has)? It would make strong passphrases much easier and less error-prone to type. Thanks! @Dantoshi@tsusanka
We are currently working on an Anonymous Delivery option, which we aim to have ready by September for the EU and by the end of the year for the US.
This gives you a safer way to order hardware wallets without linking the purchase to your home address or real-world identity.
- Dedicated checkout
- Use a nickname or label ID
- Select an automated parcel locker for pickup
- Unbranded packaging with a generic sender label, while the carrier only uses email or SMS to send a pickup PIN
This project is a top priority at the moment.
@BEN0WHERE@opchecksig@Bitkey pay in bitcoin and public point delivery is not available in europe. the app needs to be translated to spanish/french/german/etc. it would be great to connect to electrum server without ssl (umbrel) and share app key between iphone and android
@clay_garrett@isabellasg3 Clay i think you should translate the app to other mainstream languages such as spanish/french etc, like that it will reach way more people
@slush@BitsagaRob Even in the case of multivendor multisig with one coldcard the funds are at risk when sending (that’s why people used slipstream), unlike with a passphrase!
@max_guise@Bitkey Why does the bitkey iOS app label data as linked (contact, ID, usage)? Please update App Store labels to match your privacy promises @BEN0WHERE
@Fonta1n3@giacomozucco I think the priority is to use a full open source hardware wallet with a good bug bounty program. Imagine doing a 2of3 multisig with coldcard 4.0 and another similar, plus the risk of descriptors
Multiple entropy sources are only worth something if the code actually uses them. You can have four different sources of randomness in the device, but if it is using a test generator instead (code bug), none of those sources actually matter. Rolling dices doesn’t imply the device will actually use it. The entropy is not the problem here, the problem is the device not using it.
We already explained that Trezor does not use the affected code. Here are some examples of what we are already doing to make sure we do not accidentally bundle in testing RNG (random number generator):
👉 We do not use MicroPython's random module at all. It is disabled outright in our firmware config [1].
👉 rng_fill_buffer() reads the STM32 TRNG peripheral registers directly. No macro dispatch, no software path to fall through to [2].
👉 The software PRNG lives in a file literally named "crypto/rand_insecure.c", and compiling it emits "NOT SUITABLE FOR PRODUCTION USE!" warning [3].
👉 random.reseed() exists only under ifdef TREZOR_EMULATOR, and the C function behind it only under USE_INSECURE_PRNG. Two independent guards, and no reseed API in production firmware at all [4].
👉 rng_fill_buffer_strong() fills from the MCU TRNG, then XORs every byte with Optiga output (Safe 3, Safe 5) and, on Safe 7, Tropic output on top. If a secure element fails it returns false and the caller raises RuntimeError. Fail-closed, not fail-quiet on models with a secure element [5].
👉 Our Entropy check makes sure that the host’s (computer/phone) RNG is mixed in as an extra failsafe [6].
These are just some examples of how we protect from this kind of failure. That being said we never stop building and we always humbly learn from situations like these. So we are carefully studying what lessons can be learned from this incident and we are already drafting more safeguards on top [7].
You don’t have to trust me on this, our code is open-source and you can see for yourself or use your favorite AI model. See the links below. And don’t forget to ask your wallet if they can do the same…
[1] https://t.co/Ku1vLkvPbx
[2] https://t.co/0RI9e5AR1C
[3] https://t.co/biX73RTMhl
[4] https://t.co/xXitRs7EKo
[5] https://t.co/kh2zEaFFwp
[6] https://t.co/2cFN2FkXLk
[7] https://t.co/0EkIg16SGs