Вторая редакция алгоритма шифрования "пост-квантового" периода:

https://aws.amazon.com/blogs/security/round-2-hybrid-post-quantum-tls-benchmarks/

Кому ничего не ясно, но интересно, расскажу немножко про эту тему, которая часто обозначается термином long-term data security.

После сноуден-гейта все серьёзно озабоченные безопасностью на всех уровнях (военные, государственные, финансовые, медицинские и прочие структуры, а также различный бизнес), стали серьёзно подвергать сомнению распространённые и очевидные способы шифрования. Если упростить — TLS.

Очевидный прогресс TLS 1.2 → TLS 1.3 и далее (с отказом от старых версий), переход с Sha1 на Sha256/Sha384 и т.п. — всё это не давало успокоения особо параноидально настроенным господам, т.к. всё это не даёт ответа на вопрос — а что будет через 10-15 лет при такой скорости прогресса? Что если товарищи майоры всех мастей сидят и слушают, а главное — записывают всё передаваемое по шнуркам и вайфаям? Чтобы после, когда придёт недалёкое светлое и быстрое будущее, крякнуть за полчаса и узнать все тайны десятилетней давности?

Теоретические выкладки про многие тысячи лет подбора ключей не успокаивали на фоне кажущегося всемогущества спецслужб.

А тут ещё стали появляться квантовые компьютеры, которые грозят в пух и прах порвать тысячи лет подбора, потенциально сократив это до банальности.

В результате уже с пяток лет назад NSA в сообществе с заинтересованными сторонами стали разрабатывать способы подготовиться к этому, чтобы когда все смогут расшифровать условный TLS 1.4 или даже SuperTLS 2.8 за полчаса, то были способы не допустить всеобщего хаоса незащищённости.

В частности, в том числе AWS подключился и не стал изобретать ничего, а просто запилил расширение для TLS — алгоритмы SIKE и BIKE в статье выше.Их не получится поломать даже квантопутерами.

Первая редакция оказалась шибко медленной, однако это если не учитывать переиспользование шифрованной сессии — очень долгий получается TLS handshake. Вторая, улучшенная, уже "всего" в два раза медленней обычного TLS 1.2.

Алгоритм BIKE считается чуть быстрей SIKE, но жрёт много больше трафика, потому оба рассматриваются как варианты для использования.

Если интересно, можно попробовать самому, как это было в первой статье:

https://aws.amazon.com/blogs/security/post-quantum-tls-now-supported-in-aws-kms/

Итого, квантовые компьютеры кроме плюсов, могут дать и минусы. Как обычно, что бы ни придумал человек — получается оружие. А потому к этому времени нужно готовиться заранее.

п.с. кто пропустил и вдруг не знает — можно самостоятельно воспользоваться квантовыми вычислениями с помощью сервиса Amazon Braket:

https://aws.amazon.com/braket/

#security #TLS

Not so long time ago, I shared with you a tool called Acra for encryption/decryption of sensitive data in a database. This tool is written in Go, and obviously it uses TLS.

Now, they have written an article about TLS implementation in Go, specifically about the implementation of OCSP and CRL extensions.

This article would be interesting for you, foremost, to get some ideas on OCSP and CRL extensions and their use cases. Secondly, if you need to implement TLS in your apps or advise on the implementation to your developers.

#security #programming #go #tls

And another security update comes from Let's Encrypt.

Let's Encrypt will revoke all active certificates that were issued and validated with the TLS-ALPN-01 challenge before 00:48 UTC on 26 January 2022. Because of a bug, those certificates are considered mis-issued.

They estimate this is <1% of all active certificates, so it's not that bad, though.

#security #tls

So, recently I posted about the TLS vulnerability that was patched on the 1st of November.

Here someone gathered the list of affected operation systems and patched version references

Make sure to check if you’re covered!

#security #tls