Self-Defining Hash Encryption Algorithm

Question

I am looking for an algorithm to change its keys every period and can still be decrypted.
Basically, I am looking for a way to maintain a secure connection between mobile clients and a stationary server so that even if you intercept a hash or even authentication credentials, they will change on both sides every period.
Is he calling someone?
Is there a better way to make sure that even if you intercept the credentials for authentication, somehow it will only be valid for a specific request from a specific user?

Answer 1

I would recommend SSL instead of implementing some encryption algorithm myself (it will be broken if the data you are trying to protect is important enough!). SSL is well tested. with SSL, you can use certificates instead of logins / passwords. SSL prevents a person from repeating in medium attacks (he uses a handshake at the beginning to make sure that a new session key is used for each connection, and both sides are who they claim).

Another interesting thing that comes to mind is the RSA SecurID. it provides a dongle that changes every 60 seconds: http://www.rsa.com/node.aspx?id=1156

Answer 2

I suggest using SSL. It is designed to be robust enough against man-in-the-middle attacks, and this is what I assume is your problem.

Or maybe Kerberos.

Do not code encryption algorithms yourself.

Answer 3

This is certainly possible - for example, the Japanese purple cipher did this during World War II. Although such a cipher can certainly be difficult, it can also be broken (it was purple).

The reason is quite simple: your sender and recipient must generate new keys in synchronization with each other so that the recipient can decrypt messages. This basically means that you need something like a secure random number generator to generate new keys. Although it can be difficult to break (with a sufficiently long period and such), it is still a fairly common encryption technology and depends on the availability of a secure random number generator. However, if you have it, you usually don’t get much more by using the output from the generator more directly (for example, as a key for Vernam encryption).

Answer 4

I assume that you say this is to find a way to change the cryptographic key used in your algorithm periodically, so that even if the key is found, then only the data encrypted with this key can be decrypted? If we don’t worry about the startup process, one way to do this is to encode part (but not all) of your subsequent keys in the data set encrypted with one key, and when switching keys, encrypt the other part of subsequent keys with a new key.

For example, let's say that your keys are 8 elements wide (where the element can be a byte or a 32-bit word or something else), and we will call the keys you use to encrypt any given data block as Kn, where ' n 'is a block of data encrypted with this key. We will index key elements by saying Kn [0] for the 1st element, up to Kn [7] for the 8th. We will also call this data block Dn. Then the plaintext Dn will include Kn + 1 [0], Kn + 2 [1], Kn + 3 [2], ..., Kn + 8 [7]. If you could decrypt Dn-7 .. Dn, then you completely restored Kn + 1, then to decrypt the next data block, etc. You need to get plaintext for several blocks in a sequence before you can reliably decrypt the rest of the data, although getting plaintext for any given block will make it easier to attack the remainder keys.

Initial setup is a more complicated problem. SSL would be a good way to distribute K0, K1 [1..7], K2 [2..7], ..., K7 [7].

I'm not a professional cryptographer, so I'm not quite sure how safe this is. This algorithm is offered to you by AS IS, without any warranty.