Bitcoin Forum
April 19, 2024, 12:52:26 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Security question about shared wallet seeds (Bitcoin & Ethereum)  (Read 1201 times)
orientation112 (OP)
Newbie
*
Offline Offline

Activity: 3
Merit: 1


View Profile
July 09, 2017, 07:40:37 PM
Merited by ABCbits (1)
 #1

I don't have a background in cryptography, so bear with me if this is an obvious question.

Hardware wallets like Ledger Nano S can be used to set up multiple cryptocurrency wallets using a shared seed word. To be more specific, I can use one Ledger Nano S to access one Bitcoin wallet, one Ethereum wallet and so on. They all share the same seed word, which is used to derive the private key of the wallets.

So, is there any added risk when one hardware wallet is used to access multiple different cryptocurrency wallets? For instance, is it possible that the Ethereum blockchain data could at some point be broken to obtain private keys/seeds and using this information also access the Bitcoin wallet, or vice versa?

Keep in mind that there are many insecure hashing (MD4, MD5, SHA-1..) and encryption (DES, RSA with short key...) methods nowadays. In the future, probably a lot more.
1713487946
Hero Member
*
Offline Offline

Posts: 1713487946

View Profile Personal Message (Offline)

Ignore
1713487946
Reply with quote  #2

1713487946
Report to moderator
I HATE TABLES I HATE TABLES I HA(╯°□°)╯︵ ┻━┻ TABLES I HATE TABLES I HATE TABLES
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1713487946
Hero Member
*
Offline Offline

Posts: 1713487946

View Profile Personal Message (Offline)

Ignore
1713487946
Reply with quote  #2

1713487946
Report to moderator
1713487946
Hero Member
*
Offline Offline

Posts: 1713487946

View Profile Personal Message (Offline)

Ignore
1713487946
Reply with quote  #2

1713487946
Report to moderator
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3374
Merit: 6505


Just writing some code


View Profile WWW
July 09, 2017, 08:58:32 PM
 #2

The blockchain has nothing to do with your public and private keys. Hardware wallets really only deal with ECDSA public and private key pairs. The blockchain data and anything about the blockchain will not effect the security of your keys. The only thing that can expose your private keys is a vulnerability in ECDSA itself and your own stupidity.

KeepingScore
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile WWW
July 09, 2017, 10:36:55 PM
 #3

The blockchain has nothing to do with your public and private keys. Hardware wallets really only deal with ECDSA public and private key pairs. The blockchain data and anything about the blockchain will not effect the security of your keys. The only thing that can expose your private keys is a vulnerability in ECDSA itself and your own stupidity.

While I tentatively agree with what you've said, I'll add that if someone breaks SHA-256 or SHA-512 anytime soon, all three. Supposedly we'll see attacks against hardware wallets this year at Defcon or Blackhat. I'd buy a Nano S anyway, but I would keep it in my safety deposit box or safe, or in a highly secure location because it's going to be physical attacks. Someone might've come up with ways to crack mnemonics faster but that's always been an issue for brainwallets and always will be, whether 3, 6, 12, or 24 words. I do like the plausible deniability feature of the Nano S, but it may be pointless if a great attack method comes out at one of the hacking conventions this year.

To flesh it out for him, nothing is stored on your hardware wallet that isn't corresponded with in the blockchain. Your wallet isn't holding your money, it's more like a key to your safety deposit box. You personally can be held hostage for it, and it may be that this year proves that it's physically vulnerable itself. I like the Ledger Nano S over the current alternatives, but if you're looking for long-term cold storage I'd buy more than one and have some very secret hiding place that only the Executor of your Last Will and Testament will have access to.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3374
Merit: 6505


Just writing some code


View Profile WWW
July 10, 2017, 05:41:52 AM
 #4

While I tentatively agree with what you've said, I'll add that if someone breaks SHA-256 or SHA-512 anytime soon, all three.
No, breaking (by break I assume you mean a pre-image attack) SHA256 or SHA512 will not effect your private keys at all. SHA256 is not used in anything related to key derivation. SHA512 is used in key derivation, but you don't actually know the SHA512 hash unless you have a private key from the wallet, and even then, you only know half of the hash, not the full hash, so you can't find the preimage which would be the parent private key. These hash functions really are not involved in hardware wallets at all.

KeepingScore
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile WWW
July 15, 2017, 08:47:54 PM
 #5

While I tentatively agree with what you've said, I'll add that if someone breaks SHA-256 or SHA-512 anytime soon, all three.
No, breaking (by break I assume you mean a pre-image attack) SHA256 or SHA512 will not effect your private keys at all. SHA256 is not used in anything related to key derivation. SHA512 is used in key derivation, but you don't actually know the SHA512 hash unless you have a private key from the wallet, and even then, you only know half of the hash, not the full hash, so you can't find the preimage which would be the parent private key. These hash functions really are not involved in hardware wallets at all.

If someone breaks SHA-256 they'll be able to break SHA-512 in short order, relatively speaking. The orders of magnitude beyond what's being done right now say it's so. All avenues for modern cracking point to quantum state side channel attacks being the most likely candidates. Deriving a means of bypassing locks isn't what I'm referring to. And since hardware wallets rely on ECDSA for the most part (512 bits in some cases, re: BIP39), breaking SHA-256 definitely does have bearing. Standard cryptographic models aren't going allow it to be broken, but novel ones will. The fact that entropic quantum entanglement and the entanglement measure is an NP-Complete measurement means that no one's been able to look at it, except in novel effects-related efforts. I'm currently looking at electromigration as a candidate for bearing said data as it's related directly to quantum discord. Call it irrelevant if you like, but the security-level for bitcoin is based upon standard models, not taking into account measures that are outside of the boundaries. We've seen that bitcoin blocks can be falsely generated with the initial genesis block, and derive from there. Yes, that's a straw man for now, but that fact doesn't negate the weak foundations. Again, call that irrelevant or also un-prove-able. If I had a working model I'd be sitting in Maui. So, "pics or it didn't happen" all you want, I'll just leave this here so someday when it occurs I can refer back to it.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3374
Merit: 6505


Just writing some code


View Profile WWW
July 15, 2017, 09:49:40 PM
 #6

If someone breaks SHA-256 they'll be able to break SHA-512 in short order, relatively speaking. The orders of magnitude beyond what's being done right now say it's so. All avenues for modern cracking point to quantum state side channel attacks being the most likely candidates. Deriving a means of bypassing locks isn't what I'm referring to. And since hardware wallets rely on ECDSA for the most part (512 bits in some cases, re: BIP39), breaking SHA-256 definitely does have bearing. Standard cryptographic models aren't going allow it to be broken, but novel ones will. The fact that entropic quantum entanglement and the entanglement measure is an NP-Complete measurement means that no one's been able to look at it, except in novel effects-related efforts. I'm currently looking at electromigration as a candidate for bearing said data as it's related directly to quantum discord. Call it irrelevant if you like, but the security-level for bitcoin is based upon standard models, not taking into account measures that are outside of the boundaries. We've seen that bitcoin blocks can be falsely generated with the initial genesis block, and derive from there. Yes, that's a straw man for now, but that fact doesn't negate the weak foundations. Again, call that irrelevant or also un-prove-able. If I had a working model I'd be sitting in Maui. So, "pics or it didn't happen" all you want, I'll just leave this here so someday when it occurs I can refer back to it.
I never said that SHA512 is unrelated to SHA256 nor did I claim that SHA-2 functions won't be broken in the future. What I said is that these hash functions are unrelated to private keys. Can you explain how you would get private keys from public keys if SHA-2 were broken? What data in the blockchain, other than public keys, private key for a public key? What data related to hashes in the blockchain can get you the private key to a public key?

Getting the private key from a public key requires breaking ECDSA, not SHA-2. Even if you got a private key, you can't get the master private key or any other private keys in an HD wallet unless you also have the chaincode, but the chaincode is never put on the blockchain.

KeepingScore
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile WWW
July 15, 2017, 10:21:50 PM
 #7

If someone breaks SHA-256 they'll be able to break SHA-512 in short order, relatively speaking. The orders of magnitude beyond what's being done right now say it's so. All avenues for modern cracking point to quantum state side channel attacks being the most likely candidates. Deriving a means of bypassing locks isn't what I'm referring to. And since hardware wallets rely on ECDSA for the most part (512 bits in some cases, re: BIP39), breaking SHA-256 definitely does have bearing. Standard cryptographic models aren't going allow it to be broken, but novel ones will. The fact that entropic quantum entanglement and the entanglement measure is an NP-Complete measurement means that no one's been able to look at it, except in novel effects-related efforts. I'm currently looking at electromigration as a candidate for bearing said data as it's related directly to quantum discord. Call it irrelevant if you like, but the security-level for bitcoin is based upon standard models, not taking into account measures that are outside of the boundaries. We've seen that bitcoin blocks can be falsely generated with the initial genesis block, and derive from there. Yes, that's a straw man for now, but that fact doesn't negate the weak foundations. Again, call that irrelevant or also un-prove-able. If I had a working model I'd be sitting in Maui. So, "pics or it didn't happen" all you want, I'll just leave this here so someday when it occurs I can refer back to it.
I never said that SHA512 is unrelated to SHA256 nor did I claim that SHA-2 functions won't be broken in the future. What I said is that these hash functions are unrelated to private keys. Can you explain how you would get private keys from public keys if SHA-2 were broken? What data in the blockchain, other than public keys, private key for a public key? What data related to hashes in the blockchain can get you the private key to a public key?

Getting the private key from a public key requires breaking ECDSA, not SHA-2. Even if you got a private key, you can't get the master private key or any other private keys in an HD wallet unless you also have the chaincode, but the chaincode is never put on the blockchain.

Unrelated to the functions as in not used, yes, but equal in strength is equal in strength. Again, I'm not talking decryption of public->private keys being a be-all solution to cracking wallets, but the level of strength is near or at the same levels, regardless of the protocols used. If you want to talk about ECDSA and cracking chains, let's talk hardwallets, going back to the original topic at hand. It's just as hard as SHA-256 and SHA-512 respectively in ECDSA. If SHA-XX2 were broken, the equality in entropy when using BIP 39 12x and 24x word wallet is therefore breakable as they're the same level of hardness, and would generate the master key and all subkeys for the hardware wallet, and mnemonic wallets. Deterministic wallets are a failure.

As for brute force and similar cracking methods, reducing the amount of space needed to be searched to find a viable wallet is the aim of either attacks. It needn't be an attack against an individual wallet. If security precautions are taken to upgrade bitcoin further in the future, only legacy wallets will have this issue. So long as you're relying on low bit-length codes, in either SHA-XX2 or ECDSA they'll be broken. Next Generation Encryption methods aren't extended at the moment because people see no need. Collisions against cracked private keys shorten the space yet again, yielding a limited space to search for chaincodes. Analysis of transactions narrows this further. People like to quote the "heat death of the universe" as in "hell will freeze over before that" but the reality is that shortening spaces in each case will lead to successful attacks unless the chaincode, too, is extended. And even then, human fallacy comes into play.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 3374
Merit: 6505


Just writing some code


View Profile WWW
July 16, 2017, 01:41:16 AM
 #8

Unrelated to the functions as in not used, yes, but equal in strength is equal in strength. Again, I'm not talking decryption of public->private keys being a be-all solution to cracking wallets, but the level of strength is near or at the same levels, regardless of the protocols used. If you want to talk about ECDSA and cracking chains, let's talk hardwallets, going back to the original topic at hand. <snip>
You are completely misreading what OP asked about. What OP asked was:

So, is there any added risk when one hardware wallet is used to access multiple different cryptocurrency wallets? For instance, is it possible that the Ethereum blockchain data could at some point be broken to obtain private keys/seeds and using this information also access the Bitcoin wallet, or vice versa?

He asked if there was any added risk with using the same hardware wallet on multiple coins. What you are talking about is risk that already exists with hardware wallets, BIP 39, ECDSA, etc. The only added risk comes from the blockchains used by the various coins, and the blockchain has nothing to do with your keys.

KeepingScore
Newbie
*
Offline Offline

Activity: 18
Merit: 0


View Profile WWW
July 17, 2017, 08:15:46 AM
 #9

Unrelated to the functions as in not used, yes, but equal in strength is equal in strength. Again, I'm not talking decryption of public->private keys being a be-all solution to cracking wallets, but the level of strength is near or at the same levels, regardless of the protocols used. If you want to talk about ECDSA and cracking chains, let's talk hardwallets, going back to the original topic at hand. <snip>
You are completely misreading what OP asked about. What OP asked was:

So, is there any added risk when one hardware wallet is used to access multiple different cryptocurrency wallets? For instance, is it possible that the Ethereum blockchain data could at some point be broken to obtain private keys/seeds and using this information also access the Bitcoin wallet, or vice versa?

He asked if there was any added risk with using the same hardware wallet on multiple coins. What you are talking about is risk that already exists with hardware wallets, BIP 39, ECDSA, etc. The only added risk comes from the blockchains used by the various coins, and the blockchain has nothing to do with your keys.

Sorry, this is what I get for browsing bitcointalk right before bed. Oh well, hopefully someone gets a laugh out of it, or at least a chuckle.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!