0
$\begingroup$

If i need to use symmetric encryption(AES), sending the same message for many times with the same password and initial value is absolutely not secure(i don't use Public key exchange ((in first approach)'PKI,CA, etc') i will use Certificateless.

So if i used sha-256 to hash the password with public value(the current date and hour), then used the hashed value as the password

can the attacker retrive the original value of the password from the hash(he also kmow the current date and time)

The reason for asking this question: Anew a pproch called (Certificateless cryptography), Certificateless_cryptography

Certificate-Less_Authenticated

The step of trusting KGC server or trusted center(TC), is using pre definied password (known for only user and the server)encrypt the id, so the server decrypt the password and identify the ID and generate a partial private key back(encrypt it with the password)

if the user for any reason repeate the process so it's the same message (user id) same password(PKDF used)

|improve this question
$\endgroup$
  • $\begingroup$ AES doesn't use passwords, but there is a key. $\endgroup$ – Thomas M. DuBuisson Sep 29 '17 at 0:36
  • $\begingroup$ Yes, i mean a key. As the key has to be kept a secret i mistakenly said a password. I mean if the hash value updated with two values one of them is public the other could be retrieved $\endgroup$ – Sherif Awad Sep 29 '17 at 1:44
  • $\begingroup$ in the first edit you claimed i don't use Public cryptography and the Certificateless_cryptography approache is leveraging PKI without CA (trusted certificate authority). Instead of CA, other form of key distribution is used. $\endgroup$ – gusto2 Sep 29 '17 at 10:40
  • $\begingroup$ that's write i meant key exchange.( when i said like RSA), as it;s the next operation after Certificateless approach thanks, i will reformat the question $\endgroup$ – Sherif Awad Sep 29 '17 at 11:31
2
$\begingroup$

It is proposed to use $\operatorname{SHA-256}(\mathsf{horodate}\|\mathsf{password})$ as a key of AES or/and Initial Value (the lack of unique IV is stated as the motivating context).

That's a very poor idea. If the password is worth its name and is low-entropy (as most passwords are, and increasingly so since the bar for low-entropy is raising per some variant of Moore's law), then indeed the attacker can retrieve the original value of the password from the hash and time-stamp.

A general problem is ignoring the

First rule of modern crypto: don't roll your own

Ignoring that rule is a tried and tested recipe for disaster (and making a question rejected as off-topic on CSE, but I won't raise that further).

More specifically, it is ignored the

First rule of passwords: they must undergo entropy streching

Not knowing why entropy stretching is needed when turning password into key, that irreversible entropy stretching (going under the name of Password-Based Key Derivation Function) is needed for password storage, and that the first hit for PBKDF is outdated, is a sure indication that one should either learn, or leave the problem at hand to someone more knowledgeable, including for applying the first rule of crypto (commercial products that get the first rule of passwords wrong are legion, and recognizing the good from the ugly requires understanding of the issues and the products).

Even more specifically, if it is performed as planned, it will be easy to mount a password search. Yes, that thing in the movies, except one can find characters one after the other only in the most strikingly incompetent implementations of the first rule of passwords (like those vulnerable to timing attack).

Here, the regular breed of brute force password search will be needed: plausible passwords are tried (roughly from most probable to least, possibly in parallel), and for each

  1. the disastrous substitute of a PBKDF $\operatorname{SHA-256}(\mathsf{horodate}\|\mathsf{password})$ is applied ($\mathsf{horodate}$ is assumed known, and since regular decryption needs it, that's reasonable);
  2. decryption of some ciphertext(s) is attempted with that; if a direct error occurs (like incorrect padding), that password is rejected;
  3. the resulting plaintext is submitted to more plausibility test(s); the most commons are:
    • starting with a magic number appropriate to the context;
    • being sharply rejected as uniformly random octets by a chi-squared test.

That will tell when the attack has reached the right password, which will then allow decryption of all ciphertext encrypted under that password (and perhaps access to unrelated online accounts of the person using that password).

There are other lesser issues in the proposed solution:

  • Usually, the IVs are in clear at start of ciphertext; that alleviates the need for steps 2 and 3 in brute force password search.
  • If AES-256 is used, SHA-256 is not wide enough to derive key and IV; using a fixed IV with a message-unique key dents the theoretical security.
  • There is no mentioned effort to insure message integrity, which often is more important than confidentiality; see first rule of modern crypto.

Note: this answer applies to the original question, without its new flavor of Certificate-Less Authenticated Encryption.

|improve this answer
$\endgroup$
  • $\begingroup$ I edited the question and show the case of the needs of such approach. I couldn't find how using only password can do the trick(with possibility of reusing the same many times) $\endgroup$ – Sherif Awad Sep 29 '17 at 10:42
1
$\begingroup$

the same message for many times with the same password and initial value is absolutely not secure

If you are sending THE SAME message, that's maybe not so bad (effectively having ECB mode). The adversary would know it's THE message but not necessarily content of the message. But in most of the cases it's bad idea. And there's risk using different messages with the same key and IV and that can completely break your security.

So if i used sha-256 to hash the password with public value(the current date and hour), then used the hashed value as the password

If the password is really a password (something with low entropy), then use salt and PBKDF to generate a key. @fgrieu wrote nice answer about it. When using computer-to-computer communication, you can directly generate a key with length and entropy needed. .

My proposal is: Lets assume the current date and hour (or timestamp) will be unique, then - why don't you use the timestamp as IV? Until you can guarantee it is unique and not reused, the timestamp (or its hash) should be ok in most of the cases (beware some block modes are REALLY sensitive if IV is predictable, such as CBC)

can the attacker retrive the original value of the password from the hash(he also kmow the current date and time)

no, the attacker shouldn't be able to do that. However - when tthe attacker knows the time and the password has low entropy (is simple), the attacker may try to bruteforce the password

|improve this answer
$\endgroup$
  • $\begingroup$ I edited the question and show the case of the needs of such approach. $\endgroup$ – Sherif Awad Sep 29 '17 at 10:43
  • $\begingroup$ if what about using more complex password(special chars, numbers, and upper with lower chars) $\endgroup$ – Sherif Awad Sep 29 '17 at 10:45
  • $\begingroup$ If the password is worth its name and is low-entropy (as most passwords are, and increasingly so since the bar for low-entropy is raising per some variant of Moore's law), then indeed the attacker can retrieve the original value of the password from the hash and time-stamp. $\endgroup$ – fgrieu Sep 29 '17 at 10:56
  • $\begingroup$ @SherifAwad what really helps is if the password is random enough and long enough (size does matter ). Mainly if you are doing computer-to-computer communication, there's no reason for simple passwords. $\endgroup$ – gusto2 Sep 29 '17 at 11:35
  • $\begingroup$ the communication between the user and the server use Transport Layer Security(TLS), $\endgroup$ – Sherif Awad Sep 29 '17 at 12:13

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.