0

I would like to know if the following ideas are feasible:

Hash function is one-way function.

Generate public key from private key is irreversible(asymmetric cryptography).

User password entry -> SHA(or adding salt before hashing) -> hash value(as ECC private key) -> generate public key from private key -> save public key(drop private key)

Password authentication:

User password entry -> SHA(or adding salt before hashing) -> hash value(as ECC private key) -> generate public key from private key -> verify the public key with the saved one.

Based on that:

a.User or others can encrypt selected information(by using public key) that only user can decrypt it.

b.System administrator can generate a public/private key pair then both user and administrator can encrypt/decrypt selected information(by using Diffie–Hellman key exchange method).

I think that brute-force method(exhaustive attack method) can crack any password, and it is only a matter of time.It should be an another topic.

I am trying to prevent user information leak or rainbow table attack even if system being hacked.

I have searched and read the following information:

https://crypto.stackexchange.com/questions/9813/generate-elliptic-curve-private-key-from-user-passphrase

Handling user login using asymmetric cryptography

Asymmetric Cryptography as Hashing Function

5
  • 1
    A few things: 1) you should use a key derivation function rather than a simple hash. 2) how are you handling password changes? 3) a modern password hashing function with salt is pretty safe and well used.
    – Marc
    Aug 9 '20 at 4:29
  • 1
    Ignoring the erroneous key derivation, the fundamental issue with using reversible encryption instead of a one-way hash is you have the keys to the kingdom on your system. Full system compromise loses everything. Aug 10 '20 at 17:13
  • You should use a strong pepper instead of encryption. Asymmetric encryption is an even worse idea for this purpose.
    – A. Hersean
    Aug 13 '20 at 9:11
  • Thanks for answering! a.I don't want to generate an asymmetric encryption key pair. I think a hash value(SHA-2) as an ECC private key can work. And it can prevent usage of rainbow tables without saving long salt on the system. b.Password changing should not be a problem, but password forgotten would be a problem. c.Yes,long salt is safe. But we have to save it on the system.
    – W.K.Wei
    Sep 4 '20 at 8:59
  • d.ECC public key derived from private key is irreversible(hash value is irreversible). There will be only public key left on the system and every individual user's key is independent. So it can prevent user information leak even if system being hacked.
    – W.K.Wei
    Sep 4 '20 at 9:00
2

... hash value(as ECC private key) -> generate public key from private key

You are assuming that an arbitrary key (output of a hash) can be used as an ECC private key and that the public key can be derived from this. This is not how it works though. If you want to derive a key pair from an existing random string or passphrase you would need to use some deterministic random generator in the key generation process - see How can one securely generate an asymmetric key pair from a short passphrase?.

If you see the conflict between the words deterministic and random in the last sentence you might realize that this is maybe not such a great idea to do. It should be doable though.

I'm pretty sure that there is a better way to solve the actual problem you have. But currently I see only particular technical aspects in your question and not a real description of the underlying problem you are trying to solve at the end, so it is hard to tell how a better approach to the (unknown) underlying problem would be. It might be useful though that you check (and document in your question) existing approaches to your problem in more detail first before determining that you need to invent your own approach - see Why shouldn't we roll our own?.

1
  • Thanks for answering! I am not trying to prevent simple password or brute-force attack. And I don't want to generate an asymmetric encryption key pair either. I think a hash value(SHA-2) as an ECC private key can work. Then it can prevent usage of rainbow tables without saving long salt on the system. And it can prevent user information leak even if system being hacked.
    – W.K.Wei
    Sep 4 '20 at 8:36
0

I am trying to prevent user information leak or rainbow table attack

To prevent usage of rainbow tables, it is sufficient to use random long salt, e.g. 128 bit salt.

One of the links you mentioned, Asymmetric Cryptography as Hashing Function explains well disadvantages of using asymmetric cryptography for password hashing. In particular, password verification can be much faster than compared to Argon2. Means, brute-forcing can be much easier compared to Argon2.

To make brute-forcing impossible, verification of each password needs to be expensive. The algorithms like Argon2 can be configured so that verification of a every single password requires much more CPU and RAM than fast algorithms like SHA1.

That's why I'd suggest you to consider Argon2. If it is not available for you (e.g. because your customer does not allow some algorithms), consider using bcrypt, scrypt, PBKDF2.

Update

Making an algorithm complex does not make it secure.

  1. In the algorithm you use salt. But on the last step you only save the public key. This is not sufficient. You need to save also the salt, otherwise it will not be possible to verify passwords later on.

  2. The only reason your algorithm is resistant to rainbow tables is the usage of salt (provided that you use it properly, i.e. you save the salt together with public key). If you remove salt, your algorithm will not be resistant to rainbow tables.

  3. Your algorithm will be very fast. This means that brute-forcing your algorithm will be much easier for an attacker compared to properly configured password derivation algorithms like Argon2. Suppose checking of a single password with your algorithm takes 1 / 1 000 000 s and 1 K RAM. Suppose some other application uses Argon2 to hash password and hashing of a single password takes 1 s and 1 MB RAM. This means, to brute-force your database with hashed passwords an attacker will need 1 000 000 less CPU power and 1000 times less memory, means an attacker will need way less money and less time to brute-force your hashes compared to Argon2 hashes.

Despite brute-forcing of really random passwords will still be hard, it will make sense for an attacker to at least do a dictionary attack, i.e. some set of words and some common modifications of these words. Suppose an attacker takes 100 000 words and 1 000 000 modifications for each word. Thus there would be 10 000 000 000 passwords to test. If your check takes 1 / 1 000 000 s, this would take 100 000 s which is about 28 h on a single computer. If the attacker has money to rent 1 000 virtual machines for 10 days, then this will allow to test even more modifications of dictionary words. This means that at least dictionary attack may be successful.

What can you do? Use some password derivation algorithm that is resource expensive, e.g. Argon2. Configure it so that a single test takes 1 s and say 1 MB RAM on your server.

5
  • Thanks for answering! Yes,long salt is safe. But we have to save it on the system. ECC public key derived from private key is not reversible(hash value is not reversible). There will be only public key left on the system. I am not trying to prevent brute-force attack. What I am trying to: a.To prevent usage of rainbow tables. b.To prevent user information leak even if system being hacked.
    – W.K.Wei
    Sep 4 '20 at 7:39
  • In fact, I think this can work with PBKDF2, Scrypt, Bcrypt, ARGON2 or long salt.
    – W.K.Wei
    Sep 4 '20 at 7:46
  • @W.K.Wei: If somebody gets access to private key, all passwords and your whole system will be compromised. Where as the idea of salt is, that password hashing and password checking does not need any secrets. Means, if somebody gets access to your database with passwords and salts, passwords will still remain secure.
    – mentallurg
    Sep 5 '20 at 12:12
  • Thanks for answering! There is no private key left on the system. It has been discarded since the public key was generated. Password creation: User password entry -> SHA(or adding salt before hashing) -> hash value(as ECC private key) -> generate public key from private key -> save public key(drop private key) Password authentication: User password entry -> SHA(or adding salt before hashing) -> hash value(as ECC private key) -> generate public key from private key -> verify the public key with the saved one.
    – W.K.Wei
    Oct 14 '20 at 2:15
  • @W.K.Wei: I have updated the answer.
    – mentallurg
    Oct 14 '20 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.