eavesdropping on sha 256 consist of two entries one is public is secure

Question

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)

Answer 1

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.

Answer 2

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