 Привет, я Дмитрий Белявский. Я работаю в Радхат с 2020 года. Я поддерживаю OpenSEL и OpenSSH. Я тоже ухожу, чтобы быть частью технического комитета OpenSEL. Мой проект «Белафт Пэд» тоже о OpenSEL. Но сегодня я не буду говорить о OpenSEL. Я буду говорить о проявлении «Пост-Квантом Криптографии» в Федоро. Итак, я понял, что все те, кто пришли, понимают, что это криптография. Но я помню, что стремление криптографии — это сайфер, но участие людей помнится, что больше, чем сайфер. Есть сайфер, есть вирус. Индегрити-чек, есть диджетал-сигноши. И в любом случае, когда ты хочешь сайфер, что-то, что-то, ты должен присоединиться к обеим партиям. И это также таз криптографии. Итак, мы ждем момента, когда «Квантом Компьютер» появится и подбираем хотя бы несколько партий криптографий. Я говорю о диджетал-сигноши и кей-экшенж, но, конечно, некоторые другие сайферы тоже будут эффекты. Мы не знаем, когда и где «Квантом Компьютер» появится, когда я впервые слышал про это. Это было в ближайшие 5 годы, и это еще в ближайшие 5 годы. Ну, я говорю 20 годов. Все понимают, что случилось перед «Квантом Компьютер» или, скажем, «Нuclear Fusion». Но это не важно, что мы не должны быть готовы до момента, когда они реально появятся. И, так же, один из моих организаций приводит к криптографии, американские национальные институты. Они начали контакт с «Квантом Компьютер» в 2016 году. Здесь есть какие-то статистики. Там были 70 аплодисментов в первом раунде, и там были несколько раундов. И после третьего раунда в 2022 году мы выбрали 4 алгоритмы, выбрали стандартизацию, и мы тоже получили несколько алгоритмов, чтобы учиться для «Квантом Компьютер». Один из них бежит в тот момент. Итак, здесь есть 4 алгоритмы, выбранные для стандартизации. Один из них бежит для «Кэк-Чэндж». И три из них бежит для «Дигитал-Сигнажа». У них почти все, кроме «Свинкс-Пласс», так называемые «Летис-Бейст» алгоритмы. Идут в «Квантом Компьютер», в котором он в этом раунде, несколько часов назад, понимали, что это было. Я не предупреждал, что я не понимаю ничего. Итак, просто верю в, что они belong to various mathematical problems. Так что, брать один из них не будет брать другой. Итак, давайте поговорим о стандартизации процесса. Когда мы говорили, что НИСТ выбрала алгоритмы для стандартизации, ну, это не очень важно, но не очень важно, чем мы можем ожидать, потому что, когда вы выбрали алгоритмы для стандартизации, там будут какие-то параметры, и это не достаточно для стандартизации алгоритмы. Мы тоже должны стандартизовать, как эти алгоритмы, как они используются для стандартизации, как они используются в различных протоколах. Это сомнение ответственности от АИТФ, интернационной таскфорс. И мы также должны помнить, что постквантом алгоритмы тоже в сфере интересов от других групп, которые разработаны ПКС-11 стандарт. И как алгоритмы используются в ПКС-11 стандартизации, это сомнение ответственности. Так что, стандартизация нисцаря была ожидана в 2024 году. Что это значит для нас? Для нас это значит, что в следующий день нисцаря заявляет, что они стандартизировали. Мы получим несколько клиентов, чтобы имплемуать постквантом алгоритму сразу. Да, завтра, да. Мы должны уже сделали это, почему мы все это время спали. Мы надеемся, что другие стандарты в АИТФ и АИТФ и АИТФ будут готовы. И мы тоже будем готовы провести что-то. Но сейчас у нас есть сильная рекомендация от нисцаря, что никто не должен провести коммертные soluции на версии постквантом крипто, которые не стандартизированы. Так что, мы можем делать много. Что мы можем делать сейчас? Ну, сейчас мы можем использовать Федора как истинный истинный истинный истинный. Тогда в какой-то момент Федора будет в следующей версии Red Hat. И мы должны выбирать лабора. И мы должны провести какие-то эксперименты, посмотрим, что есть новые места интеграции в этой лаборе с крипто-лабором, что мы собираем и посмотрим, как они работают вместе, как различные лабороны в интераперэбли. Я буду говорить о лабороне OpenSSL, которая основана для всех серверов и для NSS, которая основана для таких популярных клиентов, как Firefox, Internet Browser и NSS implements криптографию с 11 интерфейс, поэтому я говорил о этой группе с 11 стандартизациями. OpenSSL recent version мы будем играть с так называемой Provider API. Это плагабый API что в теории позволяет создать новую крипту. И будет просто работать. Ну, это не правда. Не будет просто работать, хотя не будет просто работать с current OpenSSL releases, потому что некоторые фиши появятся только в next release 3.2, но с current releases у вас есть какой-то Provider у вас уже есть какие-то эксперименты. Итак, мы должны выбрать лабора, и наш выбор очень приятный. Это Либокс-проект. Это какого-то эко-система. Это лабора, которая я знаю, есть несколько хэкетонов и все проекты, которые используют что-то с си-бейстами, используют Либокс. Это проекты, авторы этих проектов также имплементировали OpenSSL Provider. Либокс-профайдер и работая с Либокс-профайдером OpenSSL-корре-тим. Они были лучшими, и current master поддерживает все, что может быть сейчас, когда мы имеем аналитные спецификации. Это also shares with another library, much smaller, PQClean, that will be the source of post-quantum algorithms implementations in NSS. So, it's the most significant slide in the presentation why you can't just say install Liboks, Liboks-provider and run experiments. Unfortunately, there are some license problems with Liboks. Most of the code is licensed under the mid-license, which is not the problem. There are also parts of code that are licensed under other licenses, which are fine for us, such as Apache 2 unilicense and so on and so forth. But there are some parts of code. Unfortunately, the implementation of the algorithms that we are the most interested in under Creative Commons license, which is not suitable for including Intofidora as is. We will need an exception for it. We are working on it and I hope that sometime later we will be able to include Liboks Intofidora. So again briefly a reminder about upstream PQ Readiness. Well, NSS has some implementation based on PQ Clean, but again we will meet the same license obstacles because it's exactly the same code licensed with CCO license. OpenSSL regularly tests against Liboks provider and they recently updated the version to the last current version of the Liboks. But again let me repeat, the changes are in master only. And last but not least it's a discussion topic. We don't have a final solution among ourselves because Liboks itself has several implementations of crypto-algorithms. It can use OpenSSL-based implementation of low-level algorithms such as chart 2 and chart 3 and AS. Or we can use OpenSSL implementation. It doesn't affect NSS. We don't have a problem for OpenSSL, but we in crypto team maintain two more cryptographic library Gnote LS and Lyge Crypt. As PostQuantum Crypt is needed to be implemented in most libraries at least at some moment if we use OpenSSL-based build it means that we provide some dependency between different crypto libraries which well, there are good reasons not to do it. But it's a question of near future and not of just a moment. The nearest problem we need to deal with is the lessons problem. As soon as it's built and will appear in Fedor Rohit. Thank you very much. Feel free to ask questions. How ready is PHP? BGP BGP ecosystem is not PHP Well, there are some efforts in ITF but I say they are limited. It's not the primary target of ITF standardization now. Sorry? Well, what about the cryptography used for encrypting the hard drive? Right? So, it usually uses symmetric crypt, right? Well, if K-wrap is implemented it's not a problem to add post-quantum K-wrap if it's doable. I think it's doable. I think it's not ready for now. Probably yes. Thanks, Bob. Thank you very much. Any more questions? Okay? Thank you very much.