We can extrapolate username and a password into any block-chain address, here is how.

This is an important feature when it comes to usability. Although it does make things less secure, assuming that passwords and other important data are properly stored by the centralized entity, we can get the user’s ETH address from their username. This would be a great feature for the less-advanced users. Nevertheless, they would still have to copy-paste their public key at least once. The point of this approach is not having to memorize the public key or keep the private key on any storage or a device.

Assuming such a solution that converts username and a password into ETH private key, the only problem that we have now is a communication between the ETH addresses. This means that we would have to have a database of the users and their addresses, and that all usernames will have to be unique. Furthermore, this means that such extrapolation is just a feature and it should not be integrated as a solution. It makes no sense to use it and store the public keys associated with an account in a database.

To simplify, we can only go in this direction:

key-phrase & password → Private Key → Public Key & account→ Database

So, here is how this will work. The AES (Advanced Encryption Standard) allows us to encrypt the data using an encryption password in order to get some encrypted text. Thing is, if we encrypt the encrypted text, the text simply expands and takes more memory. After several repetitions, we can generate enough text that contains numbers and characters a,b,c,d,e,f. We need 64 of those characters to generate a private key for ETH. Furthermore, we can also play around the repeated encryption steps to make it impossible to break.

Therefore, if user creates their own password and a secure word/phrase, we can generate the private and a public key for them. All of this, however, needs to be done front-end and without an Internet connection. So once the user has stored their private and public keys safely (that is, if they want to do it at all), they can log into Krakin’t portal and store their public key address in a database.

Nevertheless, this should never become the component of a Krakin’t back-end, while it can become a nice feature for people who are less advanced when it comes to storing and using their keys.