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
- 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);
- decryption of some ciphertext(s) is attempted with that; if a direct error occurs (like incorrect padding), that password is rejected;
- 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.
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