Feedback on Yeti

[fresheneesz]

I look a look at the video tutorial for Yeti level 1 and had some questions/feedback on the instructions. The videos were very helpful in seeing how Yeti operates!

1. Why are the seed words not actual words, but rather random strings? Is this a bitcoin core thing? Is the seed format created using a standard?
2. Why use a USB drive to install Ubuntu? A USB drive can have compromised firmware which could carry over viruses, and can been overwritten at a later time without the user knowing which would be a problem if its reused. Since you already have CD drives in the mix, why not burn an ubuntu CD-R and use that to boot? Not rewritable so safely reusable even on computers that may be compromised.
3. In Yeti level 2 step 7, it tells you to label the CD "Seed 1", however if you use Yeti multiple times or have other CD-based backups, "Seed 1" may not be sufficient to know what its for years down the line. I would recommend that Yeti tell users to label the CD with a date, a name that means something to the user, and then "Seed 1", for example "Primary Wallet 2021-01-25 Seed 1".
4. In Yeti level 3 step 6, couldn't 12 and 34 be combined?
5. In Yeti level 3, because you're using USB drives to transfer PSBTs, that's the largest vector for attack. A compromised USB could transfer data from the "air gapped machine" to the non-air gapped machine, and then to the internet. I'm sure you guys have thought of this and there's not a lot of options here. QR codes might be ideal here if their laptop supports that, which I assume most laptops do these days. Is that something you've considered adding as an option?
6. In Yeti level 3, you're using the same machine to generate all 7 keys. This sets up that machine a single point of failure. I would highly recommend changing this. People recommend multisignature not because there are multiple, but because it can eliminate a single point of failure. Yeti level 3 doesn't do this. Ideally with 7 keys, you'd use 7 different devices, but just like 7 different secure storage locations, that's hard to come by. If you could set up yeti keys using smartphones and hardware wallets, that would improve the situation a lot. I would recommend allowing a way to input public keys into Yeti so people could use things like Electrum on their phone to add keys external to the machines you set up in the primary Yeti setup process, or a public key from a hardware wallet. This single point of failure is my single biggest concern with Yeti level 3.
7. I didn't see any recommendations for Yeti as far as where or how to store your seed, how to interact with it once its created, etc. Users who need instructions down to "Click copy to copy the text below" will need instructions on how to properly store their CDs or paper seeds. Finding 7 different secure locations to store your seeds isn't easy, and people are going to take shortcuts a lot more often if Yeti doesn't have strong recommendations against taking shortcuts there and strong recommendations for what users should do. Users should also be instructed on maintenance of their wallet, such as checking up on their backups and verifying they haven't been tampered with and still work on a regular (eg yearly) basis.
8. Your recommended backup methods are CD-Rs and paper. It might be nice to mention M-Discs as a longer-lasting alternative to CDs. Perhaps having 7 of them makes it less necessary. And the seed format makes metal backups a lot harder, but still possible for certain methods. I'd recommend having an option for people to use a metal backup that backs up only the letters (and not the nato phonetic alphabet).
9. It would be really nice if instead of running commands on the console you could just press a button on the webpage itself to execute the command.

Thanks for working on secure guides for people to store bitcoin! Things like this are badly needed.

[JWWeatherman]

Thanks for the questions. I addressed some of them in the FAQ, but ask in slack anything you are still wondering after reading this:

https://github.com/JWWeatherman/yeticold/blob/master/FAQ.md

[fresheneesz]

Thanks! I'm reading over your new commits. For future reference for other readers:

• https://github.com/JWWeatherman/yeticold/commit/94590642a661051c4fa1d0a63807d1ceb125f1cc
• https://github.com/JWWeatherman/yeticold/commit/85cfdb992790d88680718bb23d24a1c5cec7fb3d
• https://github.com/JWWeatherman/yeticold/commit/6f0990b436422e976845c7efbcd8aec0daf47e9b
• https://github.com/JWWeatherman/yeticold/commit/aa734be216b115cc4b5b807c1ead60645d2d6de4

[fresheneesz]

@JWWeatherman I didn't see any additions in the above commits that address many of my points above. It would be nice if you could address them direcltly so we could have a conversation about it. Particuarly, my points 2, 3, 4, 5, and 6 would be interesting to discuss in more detail.

[JWWeatherman]

Those didn't seem likely to be asked often so I didn't put them in the faq, but they are worth a discussion if it can be held with other folks on the project that are more active on slack than on github if you are ok with that.

[Rspigler]

1. BIP39 is unanimously discouraged for a number of reasons. We use Core's WIF format written in the NATO phonetic alphabet with a checksum
2. We are working on using a bootable DVD-R to keep everything in RAM and remove the USB from the process
3. Working on this as well. See here: https://github.com/JWWeatherman/yeticold/issues/115
4. Not sure if this still an issue - last I checked Level 3 Steps were good
5. Working on QR codes as well. I have a $300 bounty open with Core here: https://github.com/bitcoin/bitcoin/issues/9913
6. This is the intended /purpose/ of Level 3. It gives secure "multisignature" to people who can't afford multi-devices. Level 4 is what you are looking for: https://github.com/JWWeatherman/yeticold/issues/82 Hardware wallets lie to users and tell them that they can use the device with a malicious computer, which is a lie. With Yeti, we do everything (sanely) to make sure the laptop is secure (fresh device running Ubuntu, wiped after generating keys that are geographically distributed).
7. Where/how to store CDs/seeds are now a part of the instructions and are also included in video walkthroughs
8. Metal backups would probably weigh suspiciously more (we try to pass the documents off as a Will etc). Could maybe look into an M-Disc
9. Don't think that would be secure to have a webpage serve the commands

[fresheneesz]

they are worth a discussion if it can be held with other folks on the project that are more active on slack than on github if you are ok with that.

Sure, I'm ok with that. I was thinking it would be nice for Tordl to have some kind of place for people to look through reviews of the protocols. I was wondering how you guys think about reviews of Yeti and how to make those kinds of discussions available for reference if someone wants to dig deeper on what discussions were had and what people thought about various design decisions. I can ask on slack, but slack feels ephemeral to me. Do you have any thoughts on how discussions like that can be made more easily available?

@Rspigler

1. Fair enough. Are there any proposals for doing better than BIP39?
2. 👍
3. 👍 I added a note on that #115
4. I think the steps are good, but they could be simplified for ease of use.
5. 👍
6. What I would like to see exposed to end-users via yeticold.com is some kind of enumeration of risks and benefits of each level. The only way users have to evaluate the levels on the website are the amount of bitcoin that's recommended to be stored in each level. I'd like to, for example, see information on the general categories of attack that are impossible vs relatively difficult vs relatively easy for each level. Some way of describing the attributes of each level would be very helpful for users to decide what they think is best for themselves. It would also make it much easier for reviewers to understand what is claimed and what is intended about each protocol, and match that against their actual review.
7. Has it changed since a week ago? Would you mind telling me where in the walkthrough I can see that?
8. I'm curious how you think about the concept of security by obscurity. I have always been pretty hostile towards anything you might consider security by obscurity, but I did find this article. In today's world where few attorneys are thinking about bitcoin, its probably pretty unlikely that if you pass it off as a Will they'd look at it. They probably don't care unless you're really rich or famous. This could be perhaps as much as 1000x multiplier for security on that particular key (ie 1/1000th as likely your lawyer will take a peek). However, I like to think about these things in the context of "what would happen if everyone started doing this?" If everyone was passing off CDs with their bitcoin keys to their lawyers or whatever, then this method becomes pretty much ineffective. Even honest lawyers who don't look would assume there might be some kind of valuable digital secret in any CD you give them. If the right opportunity arises, they might be tempted to take a look and compromise your security. So I would say the effectiveness of passing off the key as a Will is directly proportional to the obscurity of this protocol and the obscurity of that method of deception (by any used protocol). So if this protocol were to really become standard and millions of people were using it in the next 10 years, doing that would stop being effective then. I'm curious what your thoughts are on temporary additions to the security of the protocol. Is it worth it for the boost now, and it can be removed when it becomes ineffective? Perhaps it might be possible to make the protocol easier to use or allow for a more permanent security boost were that constraint removed.
9. Oh why not? The web page is run by a python script that's part of this library, right? Wouldn't it be just as secure? I'm not suggesting that any online webpage trigger commands to run.