Timeline for Re-sending captured encrypted data
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 23, 2015 at 5:18 | comment | added | e-sushi | @salsabear As said: that’s a (very) simplified example. In practice, you could use an authenticated cipher algorithm, or – as it’s usually done – use an according protocol for data exchange (which then includes authentication as part of the protocol). I guess an example of a somewhat alike protocol would be SSL (assuming we ignore the fact that SSL tends to require trusting a 3rd party – the certificate authority – which then acts as an mediator, confirming the identity and/or certificate of an entity/website). Diving into other Q&As tagged authentication may provide additional insights. | |
| Oct 23, 2015 at 5:11 | comment | added | e-sushi |
@salsabear Actually, Bob and Alice should always do authentication when sending messages (as each individual message needs to be authenticated). Simplified example: Bob and Alice share a common secret. When exchanging data, first the data and then the secret is hashed, based on the data’s hash as in SHA256(msg|secret). Now, Bob and Alice can authenticate exchanged data as they can hash the data (just like Mallory could) and they hash the common secret as a final step – which is where Mallory fails to authenticate (read: make Bob believe she is Alice) as she doesn’t know the secret.
|
|
| Oct 23, 2015 at 5:00 | history | edited | e-sushi | CC BY-SA 3.0 |
added 502 characters in body
|
| Oct 23, 2015 at 4:57 | comment | added | user28093 | I know a bit of encryption theory. You could be more technical in the explanation. By authentication do you mean alice decrypting the hash of a message, which is half part decided by alice and half part decided by bob? So you mean we always have to do authentication before sending messages. | |
| Oct 23, 2015 at 4:49 | history | answered | e-sushi | CC BY-SA 3.0 |