Cryptography

 
Message  integrity  
 Secrecy  vs.  integrity  
•  So  far  we  have  been  concerned  with  ensuring  
secrecy  of  communica9on  

•  What  about  integrity?  

–  I.e.,  ensuring  that  a  received  message  originated  
from  the  intended  party,  and  was  not  modified  
•  Even  if  an  a@acker  controls  the  channel!  
–  Standard  error-­‐correc9on  techniques  not  enough!  
•  The  right  tool  is  a  message  authen0ca0on  code  
 m,  t   m’,  t’  

k   k  

m   Vrfyk(m’,  t’)  =  1?  

t  =  Mack(m)  
 m,  t  
k   k  

m  
 …price=10…  

k  
cookie,  t  
cookie  

cookie,  t  

k  

cookie  
 Secrecy  vs.  integrity  
•  Secrecy  and  integrity  are  orthogonal  concerns  
–  Possible  to  have  either  one  without  the  other  

•  Encryp9on  does  not  (in  general)  provide  any  

integrity  
–  Related  to  the  issue  of  malleability  
 c1c2c  
…cn   c1c2…c’n  

k   k  

m   m1m2…m’n  
c  c  
←=  Eknc
 ⊕k  m
(m)  
 
 Message  authen9ca9on  code  (MAC)  
•  A  message  authen0ca0on  code  is  defined  by  
three  PPT  algorithms  (Gen,  Mac,  Vrfy):    
–  Gen:  takes  as  input  1n;  outputs  k.  (Assume  |k|≥n.)  
–  Mac:  takes  as  input  key  k  and  message  m∈{0,1}*;  
outputs  tag  t    
                                                             t  :=  Mack(m)  
–  Vrfy:  takes  key  k,  message  m,  and  tag  t  as  input;  
outputs  For   1  (“accept”)   all  m  and  aoll   r  0k    o
(“reject”)  
utput  by  Gen,  
Vrfyk(m,  Mack(m))  =  1    
 Security?  
•  Only  one  standard  defini9on  
•  Threat  model  
–  “Adap9ve  chosen-­‐message  a@ack”  
–  Assume  the  a@acker  can  induce  the  sender  to  
authen9cate  messages  of  the  a6acker’s  choice  
•  Security  goal  
–  “Existen9al  unforgeability”  
–  A@acker  should  be  unable  to  forge  a  valid  tag  on  
any  message  not  authen9cated  by  the  sender  
 m1,  t1  
k
m2,  t2  
t1  :=  Mack(m1)  
…
t2  :=  Mack(m2)  
…   mi,  ti  
ti  :=  Mack(mi)  
m’,  t’  

k  
Vrfyk(m’,  t’)  ??  
 Security?  
•  Is  the  defini9on  too  strong?  
–  We  don’t  want  to  make  any  assump9ons  about  
what  the  sender  might  authen9cate  
–  We  don’t  want  to  make  any  assump9ons  about  
what  forgeries  are  “meaningful”  

•  A  MAC  sa9sfying  our  defini9on  can  be  used  

anywhere  integrity  is  needed  
 Formal  defini9on  
•  Fix  A,  Π  
•  Define  randomized  experiment  ForgeA,Π(n):  
1.  k  ←  Gen(1n)  
2.  A  interacts  with  an  oracle  Mack(·∙)  ;  let  M  be  the  
set  of  messages  submi@ed  to  this  oracle  
3.  A  outputs  (m,  t)  
4.  A  succeeds,  and  the  experiment  evaluates  to  1,  if  
Vrfyk(m,  t)=1  and  m∉M  
 Security  for  MACs  
•  Π  is  secure  if  for  all  PPT  a@ackers  A,  there  is  a  
negligible  func9on  ε  such  that      
             
                               Pr[ForgeA,Π(n)  =  1]  ≤  ε(n)  
 Replay  a@acks  
•  Note  that  replay  a6acks  are  not  prevented  
–  No  stateless  mechanism  can  prevent  them  

•  Replay  a@acks  can  be  a  significant  real-­‐world  

concern  

•  Need  to  protect  against  replay  a@acks  at  a  

higher  level  
 Next  9me  
•  Construc9ng  a  secure  MAC  for  short  messages