Introduction to encryption II.
There is a problem I realize now. For the “host party” who hosts the code of the encryption software it is not difficult to update the password which is used to en- and -decrypt “secrets.”
The purpose of this would be to send a reply and simultaneously update the password. Something like:
- A to B:
- Hello friend, it is good to make contact.
- B to A:
- Likewise. Since I know you know the password let’s update it to a better one, the new one is “…”
However party A can only decrypt this message with the new password by using the old password. (Only the old password can reveal the new password)
So party B does not know at what moment in time to update the old password to the new password since she cannot be sure that A has already received the new password. Two options to this dilemma come to mind:
- The parties should make use of unique hashes which ensure the identity of the other party. Then party B has to wait one communication more before she can update the password:
- A to B:
- Hello friend, it is good to make contact. [Unique_hash(a, n) known by B proving the identity of A]
- B to A:
- Likewise. Since I know you know the password let’s update it to a better one, the new one is “xxx” [unique_hash(b, n) known by A proving the identity of B]
- A to B:
- Understood. I am ready to use new password xxx. [unique_hash(a, n-1)]
2. This is still very theoretical but the propery of electrons to exhibit quantum behaviour could communicate to the “host party” exactly when the “communicating party” would have read her message, allowing the host party to update the password on deliverance.
3. There is a third option I realize now. The “host party” can use the unique hash (generated in a large “linked list” by the communicating party1) as a new password. This would mean that each unique communicating party would need a unique interface of the encryption software.
- hash_1 = md5(random_data); …, hash_1000 = md5(hash_999);
Start communication with hash_1000 and then work back to “hash_1:” hash_1000, hash_999, etc., hash_1
If the “host” knows hash_1000 which is agreed on beforehand she can verify all subsequent communications because hash_999 and hash_998 etc. all derive from the preliminar hash ↩︎