唯一的IV使用attr_encrypted生成相同的密文

Question

使用最基本的设置:

class User < ActiveRecord::Base
  attr_encrypted :name, 
                 key: 'This is a key that is 256 bits!!', 
                 encode: true, 
                 encode_iv: true, 
                 encode_salt: true
end

提供相同名称时,结果在数据库中显示如下:

?????????????????????????????????????????????????????????
? id ? encrypted_name               ? encrypted_name_iv ?
?????????????????????????????????????????????????????????
? 1  ? aVXZb1b317nroumXVBdV9pGxA2o= ? JyE7wHups+3upY5e  ?
? 2  ? aVXZb1b317nroumXVBdV9pGxA2o= ? uz/ktrtbUAksg5Vp  ?
?????????????????????????????????????????????????????????

为什么密文相同？这不是iv的一部分,宝石默认使用它吗？

Answer 1

更新: 以下是解释整个问题的原始帖子,现在问题已修复,请参阅此答案的底部以获得解决方案.

我很确定你注意到encryptorgem中的一个相当讨厌的安全问题(用于进行attr_encrypted实际加密的gem ).

问题是当使用aes-256-gcm算法(或任何AES GCM算法)时,当前加密时确实没有考虑初始化向量(IV).该问题不会影响其他算法,但不幸的aes-256-gcm是,它是默认算法attr_encrypted.

事实证明,设置IV与加密密钥的顺序是导致问题的原因.当在密钥之前设置IV (如在宝石中)时,不考虑IV,但是如果在密钥之后设置则.

一些测试证明了这个问题:

在获取encryptorgem代码的一部分时,我创建了最简单的测试用例来证明问题(在针对OpenSSL版本编译的ruby 2.3.0下测试"1.0.1f 2014年1月6日"):

def base64_enc(bytes)
  [bytes].pack("m")
end

def test_aes_encr(n, cipher, data, key, iv, iv_before_key = true)
  cipher = OpenSSL::Cipher.new(cipher)
  cipher.encrypt

  # THIS IS THE KEY PART OF THE ISSUE
  if iv_before_key
    # this is how it's currently present in the encryptor gem code
    cipher.iv = iv
    cipher.key = key
  else
    # this is the version that actually works
    cipher.key = key
    cipher.iv = iv
  end

  if cipher.name.downcase.end_with?("gcm")
    cipher.auth_data = ""
  end

  result = cipher.update(data)
  result << cipher.final

  puts "#{n} #{cipher.name}, iv #{iv_before_key ? "BEFORE" : "AFTER "} key: " +
           "iv=#{iv}, result=#{base64_enc(result)}"
end

def test_encryption
  data = "something private"
  key = "This is a key that is 256 bits!!"

  # control tests using AES-256-CBC
  test_aes_encr(1, "aes-256-cbc", data, key, "aaaabbbbccccdddd", true)
  test_aes_encr(2, "aes-256-cbc", data, key, "eeeeffffgggghhhh", true)
  test_aes_encr(3, "aes-256-cbc", data, key, "aaaabbbbccccdddd", false)
  test_aes_encr(4, "aes-256-cbc", data, key, "eeeeffffgggghhhh", false)

  # failing tests using AES-256-GCM
  test_aes_encr(5, "aes-256-gcm", data, key, "aaaabbbbcccc", true)
  test_aes_encr(6, "aes-256-gcm", data, key, "eeeeffffgggg", true)
  test_aes_encr(7, "aes-256-gcm", data, key, "aaaabbbbcccc", false)
  test_aes_encr(8, "aes-256-gcm", data, key, "eeeeffffgggg", false)
end

运行test_encryption使用AES-256-CBC然后使用加密文本AES-256-GCM,每次使用两种不同的IV(两个方案之前/之后设置),得到以下结果:

# control tests with CBC:
1 AES-256-CBC, iv BEFORE key: iv=aaaabbbbccccdddd, result=4IAGcazRmEUIRDE3ZpEgoS0Nmm1/+nrd5VT2/Xab0WM=
2 AES-256-CBC, iv BEFORE key: iv=eeeeffffgggghhhh, result=T7um2Wgb2vw1r4uryF3xnBeq+KozuetjKGItfNKurGE=
3 AES-256-CBC, iv AFTER  key: iv=aaaabbbbccccdddd, result=4IAGcazRmEUIRDE3ZpEgoS0Nmm1/+nrd5VT2/Xab0WM=
4 AES-256-CBC, iv AFTER  key: iv=eeeeffffgggghhhh, result=T7um2Wgb2vw1r4uryF3xnBeq+KozuetjKGItfNKurGE=

# the problematic tests with GCM:
5 id-aes256-GCM, iv BEFORE key: iv=aaaabbbbcccc, result=Tl/HfkWpwoByeYRz6Mz4yIo=
6 id-aes256-GCM, iv BEFORE key: iv=eeeeffffgggg, result=Tl/HfkWpwoByeYRz6Mz4yIo=
7 id-aes256-GCM, iv AFTER  key: iv=aaaabbbbcccc, result=+4Iyn7RSDKimTQi0S3gn58E=
8 id-aes256-GCM, iv AFTER  key: iv=eeeeffffgggg, result=3m9uEDyb9eh1RD3CuOCmc50=

这些测试表明,虽然设置IV与密钥的顺序与CBC无关,但它适用于GCM.更重要的是,CBC中的加密结果对于两个不同的IV是不同的,而如果在密钥之前设置IV则不适用于GCM.

我刚刚创建了一个pull请求来解决encryptorgem中的这个问题.实际上,您现在有几个选择:

• 等到encryptor宝石的新版本发布.

• 也可以用盐attr_encrypted.无论如何,您应该使用salt来进一步保护加密数据.

非常不幸的是,所有已经加密的数据在修复后将变得难以辨认,因为突然将IV考虑在内.

更新:encryptor3.0.0可用

您现在可以将encryptorgem 升级到版本3.0,其中修复了错误.现在,如果这是您第一次使用encryptor或attr_encrypted宝石,那么您已经完成所有设置并且一切都应该正常工作.

如果您有使用encryptor2.0.0 加密的数据,则必须在gem升级后手动重新加密数据,否则将无法正确解密!宝石升级期间,您将收到警告.示意图程序如下:

• 您必须使用Encryptor该类解密所有加密数据(请参阅自述文件中的示例):v2_gcm_iv => true.这应该正确解密您的数据.
• 然后,您必须再次加密相同的数据,现在没有此选项(即:v2_gcm_iv => false),但包括数据库中的正确IV.
• 如果您有生产数据,则需要在gem更新后立即脱机执行此升级,以确保没有数据损坏.

更新2:openssl宝石确认并修复了问题

仅供参考,这是最近证实,这实际上是一个底层红宝石OpenSSL库的问题和错误已被固定现在.因此,将来,即使是attr_encryptedgem版本2.x也可能在与新的openssl-2.0.0gem版本(从2016年9月开始测试)时实际正常工作.