我们可以依靠 laravel 加密来实现未来吗？答案

【问题标题】：can we rely on laravel encryption for future?我们可以依靠 laravel 加密来实现未来吗？
【发布时间】：2018-01-20 02:06:00
【问题描述】：

我们正在构建应用程序，我们需要在数据库中存储加密的数据，而不是使用 MySql AES_ENCRYPT 和 AES_DECRYPT 我们正在使用 laravel 的内置加密和解密函数。

这是否会成为未来的证明，因为我们不想为未来的更新而丢失数据。

【问题讨论】：

我认为没有什么是真正的未来证明。一切都在发展。
如果您担心，请查看代码。 AFAIK，这些只是 PHP crypt 函数的包装器。丢失数据的唯一方法是丢失密钥。除此之外，最坏的情况是如果将来加密方法发生变化，则必须自定义包装器。
如果您打算通过更新次要/主要修订来维护库，请查看次要修订更新，我会拒绝。因为它似乎在每次修订中都发生了变化。例如：5.2 中的 $iv = random_bytes($this->getIvSize()); 与 5.4 中的 $iv = random_bytes(16);（尽管 getIvSize 返回 16）但是从纯加密方法/数据的角度来看，您必须定义所需的密钥和密码以在您的 app.php 文件中使用。 'key' => env('APP_KEY'), 和 'cipher' => 'AES-256-CBC', 在更新 PHP 的版本时也存在同样的问题。

标签： php mysql laravel laravel-5 laravel-encryption

【解决方案1】：

首先，没有什么是真正“面向未来”的。事实上，我们正处于当前加密被量子计算淘汰的边缘，这使得所有当前的加密方法非常不会被未来证明。

Taylor 有在可预见的未来改变它的计划吗？也许，也许不是，但唯一真正知道的方法是直接问他。他在 Twitter 和其他场所非常活跃，因此就企业主而言，他非常平易近人。他也是一个很好的人，所以不要害怕联系他。

But let's take a look at the code:

public function encrypt($value, $serialize = true)
{
    $iv = random_bytes(16);
    // First we will encrypt the value using OpenSSL. After this is encrypted we
    // will proceed to calculating a MAC for the encrypted value so that this
    // value can be verified later as not having been changed by the users.
    $value = \openssl_encrypt(
        $serialize ? serialize($value) : $value,
        $this->cipher, $this->key, 0, $iv
    );
    if ($value === false) {
        throw new EncryptException('Could not encrypt the data.');
    }
    // Once we get the encrypted value we'll go ahead and base64_encode the input
    // vector and create the MAC for the encrypted value so we can then verify
    // its authenticity. Then, we'll JSON the data into the "payload" array.
    $mac = $this->hash($iv = base64_encode($iv), $value);
    $json = json_encode(compact('iv', 'value', 'mac'));
    if (! is_string($json)) {
        throw new EncryptException('Could not encrypt the data.');
    }
    return base64_encode($json);
}

这是存储库中 master 的主要 encrypt() 函数，从它的外观来看，如果不完全重写它，它不太可能改变太多。虽然 Laravel 并没有真正遵循 SemVer 版本控制规范，但它通常遵循内部一致的版本控制方案，使其最有可能更改的时间是整数和第一个十进制更改（即 - 5.4 到 5.5 或 5.5到 6.0)。

但是，值得注意的是，它实际上是通过契约和服务提供者模式访问的（因此，唯一实际直接引用该类的时间是在其关联的 ServiceProvider 类中）。这意味着您现在可以使用此版本，如果将来引入了重大更改，您可以将此版本复制到您自己的加密类中，将config/app.php 中的引用替换为Illuminate\Encryption\EncryptionServiceProvider到您的新加密服务提供商，您现在已经保留了该方法，并且可以在整个应用程序中使用它，而无需对您的应用程序进行任何其他更改。

附带说明一下，如果您发现确实需要更改算法（例如，如果您的原始算法不安全），您还可以考虑编写一个“加密转换器”，通过使用旧系统的解密方法来解密所有内容，然后用新系统重新加密并再次存储。然后应用程序将继续使用新算法。

【讨论】：