It is infinitely less secure than not storing the key on the blockchain, and infinitely more secure than storing the unencrypted key on the blockchain. It is not something I would ever consider doing.
Let's break it down.
Let's say, hypothetically, that I have an ETH account with 1000ETH in it that you want. How do you go about getting it? You can't bruteforce my password, because you don't have my private key. You can't bruteforce my private key. Your only option would be to hack my computer (given that it is indeed on that computer). So, basically, it's not possible / really really hard for you to get my account.
Now, let's say hypothetically that you don't want my 1000ETH. You just want to steal ETH. How would you go about it? You might write some malware or keyloggers targeting people in the ETH community. Or you might target the clients that are creating / generating wallets. That is was happened in the Bitcoin community with the brainwallets. People saw a weakness with the creation method and exploited it to steal BTC.
In case you are not familiar, brainwallets let the end user create the seed that creates the private key which then creates the address and account. If you create a wallet via geth, you have a private key and a password that are separate. That is 2 pieces of information someone must obtain, and one of those pieces of information was randomly generated.
With brainwallets, the single seed is all you need. What makes it even more dangerous is that they let users generate the seed instead of doing it truly randomly and users are terrible at that. So people wrote scripts to generate private keys based on common password lists, etc. and therefore obtained the private key and therefore stole the funds.
How does this relate to your question? Well, you are essentially taking a private key / password pair and making it so you ONLY need the password. This is almost identical to a brainwallet in terms of what needs to happen to access the account, even if the method is different. A single word accesses the wallet, because you have already given them the encrypted private key.
There are obviously ways of mitigating, like making sure the password is truly randomly generated and has enough encryption that it is not worthwhile to bruteforce these accounts. You can also look into BIP 39 for password / mnemonic stuff.
Additionally, there is a certain level of risk / reward. Even if you add weak encryption, like an 8 character password or a password that was chosen by the user, it is more unlikely that people will attempt to break the encryption if there is only one key with 10ETH on it. If thousands of keys are stored like this then the reward gets bigger and more people dedicate more time and resources to getting them open. However, since people have been breaking into things in crypto for years now, many have modular programs that can be easily adapted to whatever mechanisms you are using to secure the account. All it takes is one bored guy, a program, and an s3 server to to bruteforce an account open. The time it takes to set up and run is the most valuable thing in that equation. The server and the program are so cheap, they may as well be free.
So, all in all, it's a pretty bad idea that can lead to some pretty bad things, especially if you are attempting to set up a service where multiple people do this. It is a huge risk, one that I would not even consider taking. As a final note, if my brain were to literally disappear and I were to decide to store my private key on the blockchain, I certainly would not label it as "encryptedPrivateKey".
Best Answer
Disclaimer: Not my domain of expertise.
Ethereum uses elliptic curve cryptography (ECC) for security. One can perform naïve brute force testing of a 256 bit key by testing all 2^256 combinations. However, similar to how it's unnecessary to test every number between
2andn - 1to test ifnis prime (worst-case high-school method isO(n^0.5), but even better algorithms exist), ECC can be broken by solving the relevant elliptic curve discrete log problem more efficiently.The best known algorithms for solving the elliptic curve discrete log problem operate in worst case
O(n^0.5);(2^256)^0.5yields2^128steps for brute forcing a 256-bit key. Hence, at most2^128trials are required to break a 256-bit key used for Ethereum. Note that this is unrelated to the birthday paradox, which pertains to collisions; the fact that both happen to be square root ofnis pure coincidence.