@pooya87

Thanks for your insightful answer! It was very helpful in understanding what I needed to know. Highly appreciated!

And sorry, I opened a bunch of tabs & then life happened, so took me a while to get back to you  

You are right, my unit tests should only test my code and not anything else.
My attempt to retest BIP32 & BIP39 would fall under integration testing, because I am testing the rightness of my package interacting with another tested package.
So disregarding semantic for unit testing here. Please bear with me on that but I am open to hear any comments you may have.

About your point on pulling out the selected code piece in a function of its own, that's very welcoming advice, as I need to get better at that front. So I have managed to refactor it & define unit tests on how I am arriving at derivation indexes based on path string. Please see here: https://github.com/ashfame/btcwallet/commit/f057f383a3bbc136dc48dac5ad2e239be9115a95

I will be adding more unit tests but with functions involving cryptographic operations like deriving addresses, what do I use as my source of truth? This is something I am still struggling with.

@pooya87 Right, so you understand why I am trying to look for test vectors that I can include and run against my code, yes?

I have already included BIP32 tests and they pass, but looking for more. Currently implementing BIP39 tests, but what other test vectors I must test against?

@NotATether Yes, I have implemented BIP32 test vectors as specified in BIP32. I will be implementing BIP39 test vectors today (atleast English to begin with). Post that, I get that in the usual sense we write test vectors ourselves because we know how something should behave or rather we can define & judge the output well. But in cryptography, since that's difficult, I am looking for test vectors written by people smarter than me, so that I can potentially find out issues with my own implementation and/or with the libraries I am using (github.com/btcsuite).

For eg: https://github.com/btcsuite/btcutil/pull/182 was fixed few months back & it was related to child derivations. If I was calculating my own test vectors, I wouldn't be able to spot this, until its brought to light. Using well-defined test vectors from bigger projects & more experienced developers in the space, is sorta assuring to some extent & helps build confidence in my project.

It's all on Github already, I am just extracting away the code from two different codebases (my last year project, but never launched) to a single package that my project can use or other implementations can rely on & I can finally release the entire project.
My current repo is here - https://github.com/ashfame/btcwallet and test vectors implemented are here - https://github.com/ashfame/btcwallet/blob/master/wallet_test.go

@pooya87 Correct, What you described as I should do, is exactly what I am trying to do. Just looking for my source of truth, I guess? Being able to check if the different addresses generated from any private key works or its broken, is good enough to start, even if that doesn't tell where the problem lies i.e. the hash, encoder etc.

Hi folks, I am working on a wallet in go lang & would like to implement some test vectors.

I have implemented BIP32 test vectors, which covers deriving private & public keys at certain paths for a specific seed.

I see some are available for BIP39 as well but doesn't seem like a proper set, just English & Japanese included in other implementations, not in BIP itself.

My main concern is that I am not able to find any test vectors, right from seed to addresses derived as per BIP44 (or other address formats) or just deriving addresses from private keys?

What would get me the highest grade of testing for correctness of wallet functionality? Any guidance is appreciated.

Thanks! So no sensitive information is ever stored on the device, which is proved that after boot you can eject the SD card before you use the vault app. SD card has a custom linux OS which completely runs off a RAM based filesystem with no swap + vault app.

Every time you have to import your mnemonic phrase + passphrase before you can manage your existing wallet. To make this a little easy, you can choose to generate an encrypted QR code (AES encryption) for your mnemonic phrase, which you can scan during import to not have to type in those 24 words. You can easily store this anywhere digitally since its AES encrypted and even if that's broken, you still have passphrase providing you 2FA. This goes along with the "extremely cautious" or "paranoia" approach I am aiming for.

Sensitive bit is indeed stored in memory after you import it and before you turn it off. Even if its encrypted, the encryption key is going to be in memory too, at some point. But what are we protecting it from at this point? Even if there is malicious programs running, where are they going to save info for any attempt of later retrieval? Is saving info on firmware and later reading from it, a possible threat? I am not very familiar with how firmware functions on Raspberry Pi. How would this supposedly work?

Now coming to physical access attacks:
1) What if someone installs a keylogger? hardware ones are easily noticeable. software ones again pose the question where do they store the info they steal? I will have an on-screen keyboard anyway. Firmware concern remains.
2) Cold boot attacks are really just proof of concept attacks. Someone in the same position, will more likely do a $5 wrench attack than anything else, for which usage of passphrase already allows plausible deniability or unlocking a "distraction" wallet with little funds when a specific non-primary passphrase is used.
3) Someone steals the device while you were using it. I have no protection against this sort of attack as of now, but I can add a reset timeout after 60s of inactivity or another auth layer before transaction is signed, though I am stepping outside of the specification here. I don't want the user to remember another thing "PIN" to sign transactions, not to bring up the fact how is PIN chosen because of the stateless nature of the device. Re-entering the passphrase can be an option but it might be inconvenient to input a long one again or perhaps only when the device has seen 60s of inactivity. What do you think about this?

Now, the goal of this project is for people to buy their raspberry pi & parts to setup their own DIY hardware wallet which is trustless by nature, effectively eliminating supply chain attacks as well. So, I can't have a lot of hardware mods in there. But I really want as much criticism as I could get to really evaluate its architecture.

Allow me to explain the architecture of the entire system & I would love for you to criticize that. Assume my intentions to be malicious for the purpose of criticism without worrying about offending me. You can forget about this question altogether, as I realized instead of aiding the user to generate mnemonic phrase in "bring your own entropy" method, its much better to do that process completely offline. So that's what I recommend now and I will provide community vetted instructions for the same.

Here is how it looks: https://imgur.com/a/JYQjrVG

Ok, so for the architecture, I am using a Raspberry Pi with a custom linux OS and the device never touches any network whatsoever, this acts as your cold storage solution. It stays offline for its entire life. Even all the Proof-Of-Concepts air-gapped attacks I came across in my research are rendered useless here as it has no speakers, no fans hence it has no medium via which malicious software can even attempt to leak out the sensitive information. The sensitive information is not stored on the device at all. You have the option of ejecting the bootable media (SD card) before you choose to use the vault app (software), so that it has no storage media to write to.

The vault app is quite simple - It has generate / import option when it starts since it never stores anything. Also make physical theft of the device useless. You always import your mnemonic any time you want to use your vault and it generates xpub keys and shows QR code which you import on the wallet software which is either a hosted service or you run it locally. You use this wallet app for all purposes of monitoring your funds, generating addresses for receiving funds & start the process of signing a transaction. All communication happens via QR codes, which can be read by a third party software at any time to see what data is being transmitted.

For convenience, you can generate an encrypted version of mnemonic and use that to import your sensitive information in the system by simply scanning that QR code, instead of having to type your mnemonic (24 words).

Now two kinds of attack that are possible on a system are:
1) Generate false crypto information (xpub keys), which can be verified from the source code
2) Stealing crypto sensitive information (mnemonic phrase or private key) which by architecture and communication medium severely limits the attack vector. Much more secure than relying on a USB/Bluetooth communication layer.

Its a free, open source DIY (self assembled) crypto vault that gives you great security at a very affordable price of ~$65 Since you put it together, there is no scope of supply chain attacks either.
That's what my goal of the project is - Enabling individuals to defend their sovereignty. Happy to discuss this further & looking forward to your criticism

Not sure why. Perhaps someone else will be able to answer.

Thank you! I realized I kinda opened a can of worms here without proper documentation 😅

I am very close to getting the MVP built out. Something before the end of this month. Most likely early. I will eventually present this to the community with motivation, documentation & security offered against several attacks, purely by architectural decisions.

Well, it was just an idea I was discussing. You probably didn't read the entire thread but I was basically trying to offer a "bring your own entropy" option at mnemonic phrase generation step, but since then I have decided that its best to do that completely offline if you are extra cautious since its a one time thing.

I am trying to reach as trustless of a system as I can build. Its not about whether I trust my RNG or not, being a software dev, I can verify it. Its about enabling individuals to have sovereign money without them getting rekkt on the security side of things.

You have a valid point about random number generation while signing a transaction, and that point isn't that a lot less severe? Once UTXO is spent, what's there to lose? Losing your mnemonic on the other hand is a big deal, but using passphrase protects against that as well.

Please poke more holes at it, if you disagree at some point or anything else. Need as many eye balls on the architecture and eventually source-code ✌

Well, as long as you use a Raspberry Pi Zero (non-W) or desolder the wifi and bluetooth module from the board if you are using any model that has wireless network options, you don't need to care about the OS at all.
I have specifically chosen this architecture based on different air-gap POC attacks as well.
The only bit you would need to verify in the application (as long as you generate mnemonic completely offline or already have one) would be just the QR codes that are passed between Wallet & Vault. Which can easily be done by a simple QR code reader


I realize that. I couldn't buy a hardware wallet because of the lockdown, so I decided to build one myself and based on my months of research, I kept on refining the architecture. I am going to do it for myself anyway and support for decentralized exchanges & dapps support is on the roadmap as well. Contributions though welcome are not required. Peer reviews and some sort of audit is what I think would do some good. I am fully committed to see it through & maintain it in the long term.

P.S. - I actually have been coding the wallet and vault, completely on live stream. YouTube and Twitch links are on my homepage - ashfame.com

Yeah, I get that point, but I was asking about internal chains, which I was able to figure out. Thanks for explaining!

I understand. And I encourage everyone to be paranoid, it would be foolish to not verify and just trust anything when it comes to cryptocurrency. Majority of the users are just going to follow the recommendations of enthusiasts / authority figures anyway, but we as enthusiasts have that responsibility to look after the community.

This project arised out of my own needs, hence I am building my own hardware wallet running a custom linux OS that can truly maintain the air-gap with the ability to verify everything from source code to the end product in hand.

Please see this diagram - https://pbs.twimg.com/media/Ec40sGxUMAA8ycM?format=png&name=large and I recommend you to read the above reply I posted as well. This is the first time I am presenting the project to the community in a lose manner, where obviously the entire vision isn't put out well enough for easy comprehension. So, I will also get to refine the vision and story, the more I talk about it.

And lastly, I hope the community encourages the open source spirit of wanting to verify everything and hacking away to deploy their principles or give voice to their opinions. Criticise it to its last bit, but do participate

Great point! I have not actually considered the act of someone doubting the generation of addresses themselves. A malicious program can print out pre-programmed xpub keys and addresses from a known list.

So, its not trustless for you because you would need to verify it yourself to build trust but you don't wish to. I understand your perspective. But if you wish to, you can and there is no step in the process that you have to just blindly trust to act in good faith.

Trustless as per me is a system where you don't have to trust the system at any point to act in good faith. Its verifiable at every point from the source code to final product in hand. And that's what I am aiming for, in the project. Scratching my own itch & learning

Right now, what I see, is one has to trust some software or the other. Its painfully slow to do it all manually that software can't be practically eliminated from the usage. So one must verify the software themselves to act in good faith or rely on others to have done the same for them.

Same reason why its recommended to build from source rather than using pre-build binaries.

Now, once you have laid down your trust in an application to use, the second concern is of the environment in which this application runs. Can you trust the environment (verifying the environment is a huge task & controlling the environment is a tough task)? How about undiscovered or undisclosed vulnerabilities which will enable the malware to take control of the system and steal funds? A better alternative is to run this application on an air-gapped device, but then several Proof of concepts of different attacks for AirGap devices exist and hence emerges the WHY of my project.

Its not just a software app. Its 2 applications where one runs on a Raspberry Pi Zero with a custom linux OS to act as an air-gapped device where its not possible to get any information out because it truly runs as an air-gap device with no networking hardware available. Another application is just the wallet, which doesn't even have access to any sensitive information, just xpub keys, so you don't need to verify this at all. Please see this diagram - https://pbs.twimg.com/media/Ec40sGxUMAA8ycM?format=png&name=large

So, in a way, this lets you build your own hardware wallet with the ability to verify everything, hence a trustless system, perhaps the only one.

oh, that's great to know, exactly what I wanted to learn

Follow up ques: If parent key at m/44'/0'/0'/0 is found to be valid, shouldn't I be checking the corresponding parent key of internal chain at m/44'/0'/0'/1 before assuming its safe to use? Otherwise we would have no valid change addresses to send money to.

Its actually not that straight forward of an attack. It can be in a closed-source but even in open source it can be hiding in plain sight. Its more like the random number generator is limited to a range of numbers either by accident (bug) or design (malicious intent) and then that range can be brute-forced comparatively easily to check for balance and steal funds from.

Also, when you buy a device, you have to "trust" it, which is why my approach is "build your own". Everything is open-source and you can review or trust others have reviewed and use the source to put together your hardware wallet (trustless), rather than relying on pre-compiled binaries (having to trust) or open yourself to supply chain attack when ordering one. You simply order Raspberry Pi, some parts, write files to SD card and done! Trustless system!

None taken, that's obviously the concern I am trying to address here. Its ideal to generate keys completely offline without a computer provided you can use verified secure entropy (as humans are bad source of entropy) and have the know-how. And then rely on an air-gapped hardware wallet to manage everything else

Now, would you go "all-manual" route to generate your keys or you would use a computer at some point in the key generation process? I am trying to offer whatever little computer tool you use in the form of an option, to mix that manual source of entropy into key generation.

Hey folks, I am building an open source air-gapped crypto vault, and as an option to not rely on system's entropy to generate random numbers, I am working on offering a "bring your own entropy" option.

This makes the system trustless, as less code about it needs to be reviewed & verified, as opposed to check whether the custom linux OS it works on, isn't acting in bad faith.
Or if you are an "Extremely cautious" user like me, you would like to do this by simply verifying how the coins flip / dice rolls are used as entropy & not worry about anything else as the device is air-gapped and runs an immutable OS without any persistence layer at all.

UI Screenshot:

My project is all about me exploring how much of a trustless system can be built.

Its my understanding flipping coin or rolling dice 256 times provide sufficient entropy to generate mnemonic, which is at par with what most computers are capable of, if not more.

So, would you be willing to do the boring manual work of flipping coin or rolling dice to record their value in order to use that as entropy?

Don't under-estimate the task. Just doing it once will take 6-10 seconds. Doing that 256 times might take you 25-45 mins.

Twitter poll is at https://twitter.com/ashfame/status/1282671325580910592.

Thanks for the pointer!

Edit: Posted it here - https://bitcointalk.org/index.php?topic=5262022.0

Thanks! Your correction is definitely precise.

About the line you quoted from BIP32, I am familiar with that, but how does it matter unless the child in question is of depth=3 in BIP32? What happens when such a case occurs in depth<3? Are we supposed to ignore it by standard or there is actual merit to it that child generated under that branch would be all invalid keys only? I think its the former, but not sure.

Skipping the account itself (depth=1) or wallet chains (depth=2) when that particular child falls outside of the acceptable private number range, sounds silly. So that's essentially where I am looking to get more clarity.

Hi,

I am building an open source air-gapped hardware vault and need opinion of users whether they would be willing to flip coin / roll dice for generating their HD wallet, therefore not requiring to trust the OS’s ability to generate random number. It’s just an alternative option to provide your own entropy for mnemonic phrase generation.

What would be the appropriate place in this forum to post? I have a poll running on twitter, can I use that or should I create it somewhere else?

Thanks!