Tag Info

New answers tagged

2

I don't mean to be blunt, but as you're inventing your own authentication algorithm, you'll almost certainly mess it up and it will be subject to many types of attacks. I strongly suggest you study the available research papers and known cryptographic authentication algorithms before you create your own so that you know what mistakes to not make. Start with ...


1

You need to take in consideration the allowable time window (to compensate for Clock drift). If you allow Date's with a time window of plus/minus 10 minutes (total: 20 minutes) you need to use nonces that are unique on the whole time window, and you also need to store spent nonces from that time period. To avoid a race situation where a nonce is being ...


8

The risk is that an attacker can forge data. In other words, they can come up with their own ciphertext and then figure out the expected HMAC to make your system accept the input as valid. The whole point of the HMAC is that only you as the owner of the key can “sign” data. However, if the application leaks information about the expected HMAC of the input, ...


18

It allows for the potential of an existential forgery. An attacker can create a valid HMAC for a chosen message without knowing the HMAC key. Basically, the way the attack works is this: The attacker sends a message, and an HMAC (really just a sequences of bytes the same length as the HMAC) and times the response from the decryption system. The ...


12

Nope Generally speaking: No. Hashing is not encryption. Hashing is not reversible. At all. It always generates a fixed length output. So with an output fixed to say 32 characters, and an input of 33 characters, there is no possible way to reverse this. The information of that one character is irretrievably lost. -- And along with it all other characters. ...



Top 50 recent answers are included