This preview shows pages 1–12. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
Unformatted text preview: MESSAGE AUTHENTICATION 1/ 103 Integrity and authenticity The goal is to ensure that M really originates with Alice and not someone else M has not been modified in transit 2/ 103 Integrity and authenticity example Alice Bob (Bank) Alice Pay $100 to Charlie a45 Adversary Eve might Modify Charlie to Eve Modify $100 to $1000 Integrity prevents such attacks. 3/ 103 Medical databases Doctor Reads F A Modifies F A to F A Get Alice a45 F A a27 Put: Alice, F A a45 Database Alice F A Bob F B Alice F A Bob F B 4/ 103 Medical databases Doctor Reads F A Modifies F A to F A Get Alice a45 F A a27 Put: Alice, F A a45 Database Alice F A Bob F B Alice F A Bob F B Need to ensure doctor is authorized to get Alices file F A , F A are not modified in transit F A is really sent by database F A is really sent by (authorized) doctor 4/ 103 Symmetric Setting We will study how to authenticate messages in the symmetric setting where Sender and Receiver share a random key K not given to the adversary. 5/ 103 Does privacy provide authenticity? Let SE = ( K , E , D ) be a (INDCPA secure) symmetric encryption scheme. Say M =Pay $100 to Bob Adversary wants Receiver to get M =Pay $1,000 to Bob Adversary needs to modify C to C such that D K ( C ) = M . Intuition: It is hard to modify C to ensure above, since modifying C will result in D K ( C ) being garbled/random and Receiver will reject. 6/ 103 Counterexample: OTP Say E K ( M ) = K M and D K ( C ) = K C . Should assume adversary knows M . Then it can let = M M and C C A K E M C C D K M = M because D K ( C ) = K C = M 7/ 103 Adding redundacy Let SE = ( K , E , D ) be a (INDCPA secure) symmetric encryption scheme. To send M , sender computes C $ E K (0 128  M ) and sends C to receiver. Receiver gets C and lets R  M D K ( C ). If R = 0 128 it outputs M else . Intuition: If C is modified to C then most probably the first 128 bits of D K ( C ) will not all be 0 and Receiver will reject. However, OTP again provides a counterexample to show that this does not provide integrity. 8/ 103 What went wrong? Possible reaction: OTP is bad! Use CBC instead. But CBC has similar problems. 9/ 103 What went wrong? Possible reaction: OTP is bad! Use CBC instead. But CBC has similar problems. The real problem: There is no good reason to think that privacy provides authenticity. Encryption is the wrong tool here. To call an encryption scheme bad because it does not provide authenticity is like calling a car bad because it does not fly. To fly you need an airplane....
View
Full
Document
This note was uploaded on 08/31/2011 for the course CSE 207 taught by Professor Daniele during the Winter '08 term at UCSD.
 Winter '08
 daniele

Click to edit the document details