如何正确区分并使用加密与认证技术？

在密码学专家之中，“加密并不是认证”是一个简单的共识。但很多不了解密码学的开发者，并不知道这句话的意义。如果这个知识更广为人知和深入理解，那么将会避免很多的设计错误。

成都创新互联是一家集网站建设,伊犁企业网站建设,伊犁品牌网站建设,网站定制,伊犁网站建设报价,网络营销,网络优化,伊犁网站推广为一体的创新建站企业，帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿，时刻以成就客户成长自我，坚持不断学习、思考、沉淀、净化自己，让我们为更多的企业打造出实用型网站。

这一概念本身并不困难，但在表面之下，还有更多丰富的细节和玄妙之处有待发现。本文就是讲述开发者对于加密和认证二者的混淆与误用，并附上了优秀的解决方案。

0x01 加密与认证之间有哪些区别?

加密是呈现信息，使其在没有正确的密钥情况下，变得难以卒读的过程。在简单的对称加密中，同一个密钥被用于加密和解密。在非对称加密中，可以使用用户的公钥对信息加密，使得只有对应私钥的拥有者才能读取它。

认证是呈现信息，使其抗篡改(通常在某一非常低的概率之内，小于1除以已知宇宙中粒子的数量)，同时也证明它起源于预期发送者的过程。

注意：当本文提及真实性时，是专门指的信息真实性，而不是身份真实性。这是一个PKI和密钥管理问题，我们可能在未来的博客中详细说明。

就CIA triad而言：加密提供机密性，认证提供完整性。

加密不提供完整性;被篡改的信息(通常)还能解密，但结果通常会是垃圾。单独加密也不抑制恶意第三方发送加密信息。

认证不提供机密性;可以为明文信息提供抗篡改。

在程序员中，常见的错误是混淆这两个概念。你能很容易找到这样的一个库或者框架：加密cookie数据，然后在仅仅解密它之后就无条件地信任与使用之。

0x02 加密

我们之前定义了加密，并且详细说明了它是提供机密性，但不提供完整性和真实性的。你可以篡改加密信息，并将产生的垃圾给予接收者。而且你甚至可以利用这种垃圾产生机制，来绕过安全控制。

考虑在加密cookie的情况下，有如下代码：

 
 
    
  
  
  1. function setUnsafeCookie($name, $cookieData, $key) 
    2. 
  
  
  2. { 
    3. 
  
  
  3.     $iv = mcrypt_create_iv(16, MCRYPT_DEV_URANDOM); 
    4. 
  
  
  4.     return setcookie( 
    5. 
  
  
  5.         $name,  
    6. 
  
  
  6.         base64_encode( 
    7. 
  
  
  7.             $iv. 
    8. 
  
  
  8.             mcrypt_encrypt( 
    9. 
  
  
  9.                 MCRYPT_RIJNDAEL_128, 
    10. 
  
  
  10.                 $key, 
    11. 
  
  
  11.                 json_encode($cookieData), 
    12. 
  
  
  12.                 MCRYPT_MODE_CBC, 
    13. 
  
  
  13.                 $iv 
    14. 
  
  
  14.             ) 
    15. 
  
  
  15.         ) 
    16. 
  
  
  16.     ); 
    17. 
  
  
  17. } 
    18. 
  
  
  18. function getUnsafeCookie($name, $key) 
    19. 
  
  
  19. { 
    20. 
  
  
  20.     if (!isset($_COOKIE[$name])) { 
    21. 
  
  
  21.         return null; 
    22. 
  
  
  22.     } 
    23. 
  
  
  23.     $decoded = base64_decode($_COOKIE[$name]); 
    24. 
  
  
  24.     $iv = mb_substr($decoded, 0, 16, '8bit'); 
    25. 
  
  
  25.     $ciphertext = mb_substr($decoded, 16, null, '8bit'); 
    26. 
  
  
  26.   
    27. 
  
  
  27.     $decrypted = rtrim( 
    28. 
  
  
  28.         mcrypt_decrypt( 
    29. 
  
  
  29.             MCRYPT_RIJNDAEL_128, 
    30. 
  
  
  30.             $key, 
    31. 
  
  
  31.             $ciphertext, 
    32. 
  
  
  32.             MCRYPT_MODE_CBC, 
    33. 
  
  
  33.             $iv 
    34. 
  
  
  34.         ), 
    35. 
  
  
  35.         "\0" 
    36. 
  
  
  36.     ); 
    37. 
  
  
  37.   
    38. 
  
  
  38.     return json_decode($decrypted, true); 
    39. 
  
  
  39. }
    40.

上面的代码提供了在密码段链接模块的AES加密，如果你传入32字节的字符串作为$key，你甚至可以声称，为你的cookie提供了256位的AES加密，然后人们可能被误导相信它是安全的。

0x03 如何攻击未经认证的加密

比方说，在登录到这个应用程序之后，你会发现你收到一个会话cookie，看起来就像

kHv9PAlStPZaZJHIYXzyCnuAhWdRRK7H0cNVUCwzCZ4M8fxH79xIIIbznxmiOxGQ7td8LwTzHFgwBmbqWuB+sQ==

让我们改变一个字节的第一块(初始化向量)，并反复发送我们的新的cookie，直到出现一些变化。应该采取共4096次HTTP请求，以尝试变量IV所有可能的单字节变化。在上面的例子中，经过2405次请求后，我们得到一个看起来像这样的字符串：

kHv9PAlStPZaZZHIYXzyCnuAhWdRRK7H0cNVUCwzCZ4M8fxH79xIIIbznxmiOxGQ7td8LwTzHFgwBmbqWuB+sQ==

相比之下，在base64编码的cookie中只有一个字符不同(kHv9PAlStPZaZ J vs kHv9PAlStPZaZ Z)：

- kHv9PAlStPZaZJHIYXzyCnuAhWdRRK7H0cNVUCwzCZ4M8fxH79xIIIbznxmiOxGQ7td8LwTzHFgwBmbqWuB+sQ==

+ kHv9PAlStPZaZZHIYXzyCnuAhWdRRK7H0cNVUCwzCZ4M8fxH79xIIIbznxmiOxGQ7td8LwTzHFgwBmbqWuB+sQ==

我们存储在这个cookie里的原始数据，是看起来像这样的数组：

 
 
    
  
  
  1. array(2) { 
    2. 
  
  
  2.   ["admin"]=>
    3. 
  
  
  3.   int(0) 
    4. 
  
  
  4.   ["user"]=>
    5. 
  
  
  5.   "aaaaaaaaaaaaa" 
    6. 
  
  
  6.  }
    7.

但在仅仅改变初始化向量的一个字节之后，我们就能够改写我们的阅读信息：

 
 
    
  
  
  1. array(2) { 
    2. 
  
  
  2.   ["admin"]=>
    3. 
  
  
  3.   int(1) 
    4. 
  
  
  4.   ["user"]=>
    5. 
  
  
  5.   "aaaaaaaaaaaaa" 
    6. 
  
  
  6. }
    7.

根据底层应用程序的设置方法，你或许可以翻转一位进而提升成为一名管理员。即使你的cookie是加密的。 如果你想再现我们的结果，我们的加密密钥是十六进制下的：000102030405060708090a0b0c0d0e0f

#p#

0x04 认证

如上所述，认证旨在提供信息的完整性(我们指显著抗篡改能力)，而这证明它来自预期的源(真实性)。这样做的典型方法是，为信息计算一个密钥散列消息认证码(HMAC的简称)，并将信息与它连结。

 
 
    
  
  
  1. function hmac_sign($message, $key) 
    2. 
  
  
  2. { 
    3. 
  
  
  3.     return hash_hmac('sha256', $message, $key) . $message; 
    4. 
  
  
  4. } 
    5. 
  
  
  5. function hmac_verify($bundle, $key) 
    6. 
  
  
  6. { 
    7. 
  
  
  7.     $msgMAC = mb_substr($bundle, 0, 64, '8bit'); 
    8. 
  
  
  8.     $message = mb_substr($bundle, 64, null, '8bit'); 
    9. 
  
  
  9.     return hash_equals( 
    10. 
  
  
  10.         hash_hmac('sha256', $message, $key), 
    11. 
  
  
  11.         $msgMAC 
    12. 
  
  
  12.     ); 
    13. 
  
  
  13. }
    14.

重要的是，这里使用一个适当的哈希工具，如HMAC，而不仅仅是一个简单的散列函数。

 
 
    
  
  
  1. function unsafe_hash_sign($message, $key) 
    2. 
  
  
  2. { 
    3. 
  
  
  3.     return md5($key.$message) . $message; 
    4. 
  
  
  4. } 
    5. 
  
  
  5. function unsafe_hash_verify($bundle, $key) 
    6. 
  
  
  6. { 
    7. 
  
  
  7.     $msgHash = mb_substr($bundle, 0, 64, '8bit'); 
    8. 
  
  
  8.     $message = mb_substr($bundle, 64, null, '8bit'); 
    9. 
  
  
  9.     return md5($key.$message) == $msgHash; 
    10. 
  
  
  10. }
    11.

我在这两个函数名前面加了unsafe，是因为它们还是易受到一些缺点的危害：

Timing Attacks

Chosen Prefix Attacks on MD5 (PDF)

Non-strict equality operator bugs (largely specific to PHP)

现在，我们有点接近我们强大的对称加密认证的目标。目前仍有几个问题，如：

如果我们的原始信息以空字节结尾会发生什么?

有没有一个比mcrypt扩展库默认使用的更好的填充策略?

由于使用AES，有哪些通信方面是易受攻击的?

幸运的是，这些问题在现有的加密函数库中已有了解答。我们强烈推荐你使用现有的库，而不是写自己的加密功能。对于PHP开发人员来说，你应该使用defuse/php-encryption(或者libsodium)。

0x05 用Libsodium安全加密Cookies

 
 
    
  
  
  1. /* 
    2. 
  
  
  2. // At some point, we run this command: 
    3. 
  
  
  3. $key = Sodium::randombytes_buf(Sodium::CRYPTO_AEAD_CHACHA20POLY1305_KEYBYTES); 
    4. 
  
  
  4. */ 
    5. 
  
  
  5.   
    6. 
  
  
  6. /** 
    7. 
  
  
  7.  * Store ciphertext in a cookie 
    8. 
  
  
  8.  *  
    9. 
  
  
  9.  * @param string $name - cookie name 
    10. 
  
  
  10.  * @param mixed $cookieData - cookie data 
    11. 
  
  
  11.  * @param string $key - crypto key 
    12. 
  
  
  12.  */ 
    13. 
  
  
  13. function setSafeCookie($name, $cookieData, $key) 
    14. 
  
  
  14. { 
    15. 
  
  
  15.     $nonce = Sodium::randombytes_buf(Sodium::CRYPTO_SECRETBOX_NONCEBYTES); 
    16. 
  
  
  16.   
    17. 
  
  
  17.     return setcookie( 
    18. 
  
  
  18.         $name, 
    19. 
  
  
  19.         base64_encode( 
    20. 
  
  
  20.             $nonce. 
    21. 
  
  
  21.             Sodium::crypto_secretbox( 
    22. 
  
  
  22.                 json_encode($cookieData), 
    23. 
  
  
  23.                 $nonce, 
    24. 
  
  
  24.                 $key 
    25. 
  
  
  25.             ) 
    26. 
  
  
  26.         ) 
    27. 
  
  
  27.     ); 
    28. 
  
  
  28. } 
    29. 
  
  
  29.   
    30. 
  
  
  30. /** 
    31. 
  
  
  31.  * Decrypt a cookie, expand to array 
    32. 
  
  
  32.  *  
    33. 
  
  
  33.  * @param string $name - cookie name 
    34. 
  
  
  34.  * @param string $key - crypto key 
    35. 
  
  
  35.  */ 
    36. 
  
  
  36. function getSafeCookie($name, $key) 
    37. 
  
  
  37. { 
    38. 
  
  
  38.     $hexSize = 2 * Sodium::Sodium::CRYPTO_SECRETBOX_NONCEBYTES; 
    39. 
  
  
  39.     if (!isset($_COOKIE[$name])) { 
    40. 
  
  
  40.         return array(); 
    41. 
  
  
  41.     } 
    42. 
  
  
  42.   
    43. 
  
  
  43.     $decoded = base64_decode($_COOKIE[$name]); 
    44. 
  
  
  44.     $nonce = mb_substr($decoded, 0, $hexSize, '8bit'); 
    45. 
  
  
  45.     $ciphertext = mb_substr($decoded, $hexSize, null, '8bit'); 
    46. 
  
  
  46.   
    47. 
  
  
  47.     $decrypted = Sodium::crypto_secretbox_open( 
    48. 
  
  
  48.         $ciphertext, 
    49. 
  
  
  49.         $nonce, 
    50. 
  
  
  50.         $key 
    51. 
  
  
  51.     ); 
    52. 
  
  
  52.     if (empty($decrypted)) { 
    53. 
  
  
  53.         return array(); 
    54. 
  
  
  54.     } 
    55. 
  
  
  55.   
    56. 
  
  
  56.     return json_decode($decrypted, true); 
    57. 
  
  
  57. }
    58.

对于没有libsodium库的开发人员，我们的一个博客读者，提供了一个安全cookie实现的例子，其使用了defuse/php-encryption(我们推荐的PHP库)。

0x06 使用关联数据的认证加密

在我们前面的示例中，我们集中精力于，同时使用加密和认证，使其作为必须小心使用的单独组件，以避免加密的悲剧。具体而言，我们专注于密码段链接模块的AES加密。

然而，密码学家已经开发出更新，更具有弹性的加密模型，其加密和认证信息在同一操作。这些模型被称为AEAD模型(Authenticated Encryption with Associated Data)。关联数据意味着，无论你的应用程序需要什么进行认证，都不加密。

AEAD模型通常用于有状态的目的，如网络通信中，其中一个随机数可以很容易地管理。

AEAD两个可靠的实现是AES-GCM和ChaCha20-Poly1305。

AES-GCM是Galois/Counter模式中的高级加密标准(又名Rijndael算法加密)。这种模式在OpenSSL的最新版本中加入，但它目前在PHP中还不被支持。

ChaCha20-Poly1305结合了ChaCha20流密码与Poly1305消息认证码。这种模式在libsodium PHP扩展可用。Sodium::crypto_aead_chacha20poly1305_encrypt() Sodium::crypto_aead_chacha20poly1305_decrypt()

总结一下，你该记住的

加密不是认证

加密提供机密性

认证提供完整性

将两者混为一谈你就得自担风险

为了完成CIA triad，你需要单独解决可用性。这通常不是一个加密问题。

更重要的是：在密码学专家的监督下，使用具有韧性被证实记录的库，而不是自己在那里闭门造车，你会好得多。

原文：https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly

网站栏目：如何正确区分并使用加密与认证技术？
分享地址：http://www.hantingmc.com/qtweb/news28/175078.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

电子商务知识

同城分类信息

温江做网站　　 　物流公司网站建设方案　　 　seo优化　　 　商城网站建设　　 　微信公众号开发　　 　成都网站推广　　 　做移动网站　　 　南宁旺客科技　　 　云服务器　　 　成都定制网站建设　　 　成都包装盒设计　　 　营销推广　　 　机柜租用　　 　成都logo设计标志　　 　南充做网站　　 　定制网站建设　　 　温江网站设计　　 　成都多线机房　　 　成都app软件开发　　 　网站推广优化