Hot answers tagged

6

My only idea is that B authenticates himself to A, because if A later decrypts it, A will see whether B was able to decrypt it. But why would you need to increment the nonce? Correct, that's the idea. If B didn't need to increment the nonce and just encrypted the same value, the message sent back would be the same that A sent, so an attacker would be ...


3

I'm answering this based on the TLS v1.2 certificate based client authentication feature. Other protocols may vary in the details. Can anybody tell me what is being sent from the user's side for getting authentication from the server? The overhead to a normal handshake consists only of the user's certificate (+ intermediate certificates eventually, ...


3

To answer your first question, the incrementation is required in order to prevent spoofing of that message. An attacker could send back the same encrypted nonce claiming to be Bob. However, if Bob incriments the nonce and sends it back encrypted, Alice would know for sure that Bob has received the nonce and has incremented it. Now, Alice encrypting the ...


3

That doesn't hide Bob's identity from eavesdroppers. (The OP mentioned in chat that the OP isn't trying to do that.) I can no longer spot any other problems with the key exchange part. The encryption/decryption of application level data is vulnerable to arbitrary replays and reflection and dropping. ‚Äč The public MAC input should indicate direction and ...


1

Can anyone suggest an example of an application where we need to know who sent the data but it doesn't really matter if they later deny that they sent it? I would argue that most situations where you need authentication are like this. You very rarely need to be able to prove anything to third parties. For example, if you have a TLS connection to a ...



Only top voted, non community-wiki answers of a minimum length are eligible