мы можем положиться на шифрование Laravel для будущего?

Прежде всего, ничто не является действительно «будущим». Фактически, мы находимся на грани того, что текущее шифрование становится устаревшим в результате квантовых вычислений, что делает все современные методы шифрования очень не на будущее.

Есть ли у Тейлора какие-либо планы изменить его в обозримом будущем? Может быть, а может и нет, но единственный реальный способ узнать это спросить его напрямую. Он довольно активен в Твиттере и в других местах, поэтому с точки зрения владельцев бизнеса он довольно доступен. Он также в целом хороший человек, так что не бойтесь пинговать его.

Но давайте посмотрим на код:

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);
}

Это основная функция encrypt () от master в репозитории, и, судя по всему, ее вряд ли можно будет изменить слишком сильно, не переписав полностью. И хотя Laravel на самом деле не следует спецификации версий SemVer, он, как правило, следует внутренне согласованной схеме управления версиями, поэтому наиболее вероятные времена для его изменения — целое число и первое десятичное изменение (т. Е. От 5,4 до 5,5 или 5,5 до 6,0).

Тем не менее, стоит отметить, что к нему фактически обращаются через контракты и шаблон поставщика услуг (поэтому единственный раз, когда на класс ссылаются непосредственно, это связанный с ним класс ServiceProvider). Это означает, что вы можете использовать это пока является В будущем, вы можете скопировать эту версию в свой собственный класс шифрования, заменить ссылку в config/app.php в Illuminate\Encryption\EncryptionServiceProvider новому поставщику услуг шифрования, и вы сохранили этот метод и можете использовать его в своем приложении, не внося никаких других изменений в свое приложение.

Немного побочного примечания: вы также можете подумать о написании «конвертера шифрования», если вы обнаружите, что вам нужно изменить алгоритмы (например, если ваш оригинальный алгоритм небезопасен), используя метод расшифровки старой системы для дешифрования всего, затем — зашифровать все это с помощью новой системы и снова сохранить. Затем приложение будет просто использовать новый алгоритм.