Соверен потому не фунт, что монета так называлась - "соверен", а монеты "фунт" не было?
Это основная причина, да. Соверен 1817 года – золотая монета, которая, собственно, привязала фунт к золоту.
Но покупательная способность была одинаковой?
Это как посмотреть. Формально, да, такая же. Потому что соверен – те же двадцать шиллингов, что и фунт. Но зато соверен дан в золоте и прямо тут. У золотой монеты в викторианской Великобритании универсальность была сильно выше, чем у прочих вариантов. Например, банкноты вообще были не в ходу, были чем-то очень специальным.
Я исхожу вот из чего: признаком использования системы, отличной от десятеричной, является счёт по алтынам и деньгам, а не только по 100-копеечным рублям. Раз Пётр Первый, вроде как, прямо запрещал счёт по алтынам и деньгам, и требовал удаления соответствующего блока-ящика на счётах, значит, счёт такой всё ещё сохранялся при Петре дажев государственной системе.
Более того, когда при Петре Первом выпустили пять копеек, то назвали их 10 денег (напоминает шиллинги и новые пенсы), что, как бы, тоже прямо указывает на сохраняющееся параллельное использование старой системы, несмотря на имевшую место реформу, которую провела Елена Глинская. Но основу заложила Елена Глинская, судя по всему.
Основная задача криптографии – преобразовывать обычный текст в нечитаемый набор символов.
И вроде очевидно, что это не так, что это не «основная задача криптографии», но почему-то кочует из публикаци в публикацию данная формулировка. Нет, «преобразовывать обычный текст в нечитаемый набор символов» – это задача для хорошего шредера. А задача криптографии, применительно к зашифрованию, состоит в обратимом сокрытии статистических свойств открытого текста. При этом зашифровать можно и так, что шифротекст будет вполне себе «читаемым набором символов» – делов-то: «U2FsdGVkX1+yfyqjFLE8oJn5aokoCoaHwvd2UFW6lFO61I8B/nP+zA==» – все символы читаемые; можно вообще слова или фразы на естественном языке использовать. Сложно вычислить открытый текст, не зная подходящего ключа, это да.
В теории да, но в практических реализациях это не всегда так.
Из опыта, основная проблема в том, что разработчики делают неверное обобщение и полагают, что можно обычным способом сравнивать значенияпеременных, имеющих тип float. То есть, дело не в сравнении конкретной записи – это сравнение определено как побитовое, и в стандарте оно строгое, детерминированное. Формально, два строгих float сравниваются точно. Но это не обобщается. Дело в том, что float – это не число, а некоторый алгоритм. Поэтому, концептуально, нужно сравнение понимать так, как если бы сравнивались алгоритмы.
Собственно, в статье примерно про это и написано:
Настоящее правило: избегайте ==, если значения прошли через сложные вычисления, в которых округление может отличаться. Не полагайтесь на то, что алгебраические законы (ассоциативность, дистрибутивность) действуют точно.
Я бы только подчеркнул, что ни ассоциативность, ни дистрибутивность – не могут действовать "не точно", по определению. Поэтому-то и не нужно полагать, что эти свойства есть во float. Дистрибутивность, скажем, там не работает в совсем простых случаях – вот я недавно приводил пример: https://dxdt.ru/2025/08/31/16204/
С самого начала компания помогала разрабатывать и поддерживать систему Certificate Transparency, что позволило выявить этот факт ненадлежащей выдачи
Позволило-то – позволило, но вот больше года никто ничего не замечал подозрительного, в том числе и Cloudflare, которые являются оператором нескольких логов Certificate Transparency и предоставляют сервис мониторинга.
Всегда удивляет это утверждение. Компьютеры работают в подмножестве наутральных чисел, а вот ML - каким-то образом в . Как такое возможно, если речь явно не про символьные вычисления, а большинство действительных чисел не получится даже записать в конечную память?
Эти записи указывают, что TLSA-записи для портов 25, 587 и 993 следует искать по имени _dane.myzone.tdl.
Всё ж, CNAME с разных номеров сервисов на единую нестандартную запись, да ещё с другим именем хоста в её составе, – не очень хорошая идея. Лучше бы публиковать индивидуальные TLSA под теми именами/номерами, к которым они относятся. (CNAME – вообще не очень хорошая штука, за очень редкими исключениями, а в паре с DNSSEC – так ещё хуже.)
changetype: REPLACE (полностью заменяет существующие TLSA-записи для этого имени).
Тут бы нужно предусмотреть период ожидания для замены серверного сертификата (rollover): то есть, выкатывать новую TLSA-запись для нового сертификата заранее, рядом со старой, а переходить на новый сертификат только после того, как истечёт TTL (лучше – два TTL) старой TLSA-записи; после перехода на новый сертификат – удалять TLSA-запись для старого.
Я вот допускаю существование гипервизора! Но он совершенно не обязан работать на той логике, которую предполагает автор. Он вообще может просто число Пи в бесконечную дробь разворачивать, а из этого разворота и будут вытекать все разбитые чайники... Ему даже не нужна "обратная связь" ;)
Может быть и так, но тогда на стороне гипервизора возникнет проблема с тем, чтобы как-то согласовать результат разбиения чайника с результатами вычислений, которые, – опять же, внутри симуляции, – жители проводят на собственном суперкомпьютере. Если брать знаки записи π, то потом придётся «местное время» откручивать назад. Тоже, конечно, интересный вариант, но затратный.
Так с чего же автор постулирует, что науке, якобы, известны все законы математики и логики?
Математика/логика – должны хотя бы сходиться на некотором подмножестве «законов», иначе и рассуждать-то о гипервизоре не получится.
Всё ж, если верить описанию методики на исходном сайте, то не на статистике поиска, а на «количестве упоминаний» в выдаче «систем поиска». А это количество упоминаний они определяют по показателю счётчика хитов, который вывела та или иная система в ответ на запрос.
Причём, к «системам поиска», согласно методике, относится и «поиск по сайту» на wikipedia.org, microsoft.com, amazon.com, ebay.com и др. - список опубликован. Ну, то есть, это даже не рейтинг по количеству статей, а рейтинг по счётчикам, выводимым в результатах обработки поискового запроса. Понятно, что Python нынче будет на первом месте, даже про ИИ можно и не упоминать.
Это вряд ли из-за OCSP для LE. В их действующих TLS-сертификатах уже не должно быть ссылок на OCSP, а проверять отзыв для сертификата, у которого закончился срок действия, смысла нет (ну, разве что, вручную потестировать корректность настройки OCSP). Но, возможно, недоступна точка раздачи CRL.
Это тоже, согласен. С одной стороны, поток сертификатов увеличится и поддерживать OCSP станет ещё труднее; с другой стороны – TLS-сертификаты сейчас превращают в безотзывные кратковременные токены разрешения доступа пользователей, которые центральный сервис выдаёт узлам, публикующим веб-страницы и другую информацию, так что и OCSP, и CRL становятся технологической обузой.
Не нужно называть «шифрованием» процесс вычисления цифровой подписи – это неверно. Почему-то данная ошибка много лет кочует из статьи в статью. Подписывание – это совсем не «шифрование», это совсем другой процесс – и по назначению, и по логике применения, и по алгоритмам.
(Криптосистемы, кстати, называют «асиммметричными», не «асинхронными».)
Если в тексте самом по себе нет смысла, то такой текст никому не нужен, потому что с помощью него нельзя передать никакой информации
Всё ж, информация и смысл - вещи разного уровня. В тексте может быть только один бит информации ("да/нет"), но очень и очень много смысла для конкретного читателя, а может - наоборот.
На картинке потерялся кусочек с "00.4e 25" -> "00.01 -1" <- "00.19 4a". А это как раз точки с уникальной Y-координатой.
for k in range(1,h): Pn =63*P
Так как - достаточно написать: for k in range(1,4).
И таких кучек ровно 12. Обратите внимание, что во всех точках каждого цикла значения y координаты Y одинаковые.
А это всё потому, что 36 = 12 * 3.
Вот рисунок этой кривой над :
Кривая и прямые
Зелёным проведены прямые, на которых лежат точки с равными Y-координатами, таких точек, обычно, три. Две "потерявшихся" точки - (0x00, 0x4e) и (0x00, 0x19).
Это удивительные закономерности, точки эллиптической кривой оказались очень хорошо структурированы.
Вообще, так как в уравнении кривой справа кубика, а кривая - это группа, где, по определению сложения точек, A + B + C == O, то этим 111 точкам, при разбиении их на 12 подмножеств по 9 элементов (с остатком), со "сдвигами" в 63*G (63 == 3*3*7, GCD(111, 63) == 3), просто некуда будет деваться.
А так - в теории чисел сложно найти что-то более структурированное, чем эллиптические кривые.
Это основная причина, да. Соверен 1817 года – золотая монета, которая, собственно, привязала фунт к золоту.
Это как посмотреть. Формально, да, такая же. Потому что соверен – те же двадцать шиллингов, что и фунт. Но зато соверен дан в золоте и прямо тут. У золотой монеты в викторианской Великобритании универсальность была сильно выше, чем у прочих вариантов. Например, банкноты вообще были не в ходу, были чем-то очень специальным.
Я исхожу вот из чего: признаком использования системы, отличной от десятеричной, является счёт по алтынам и деньгам, а не только по 100-копеечным рублям. Раз Пётр Первый, вроде как, прямо запрещал счёт по алтынам и деньгам, и требовал удаления соответствующего блока-ящика на счётах, значит, счёт такой всё ещё сохранялся при Петре даже в государственной системе.
Более того, когда при Петре Первом выпустили пять копеек, то назвали их 10 денег (напоминает шиллинги и новые пенсы), что, как бы, тоже прямо указывает на сохраняющееся параллельное использование старой системы, несмотря на имевшую место реформу, которую провела Елена Глинская. Но основу заложила Елена Глинская, судя по всему.
И вроде очевидно, что это не так, что это не «основная задача криптографии», но почему-то кочует из публикаци в публикацию данная формулировка. Нет, «преобразовывать обычный текст в нечитаемый набор символов» – это задача для хорошего шредера. А задача криптографии, применительно к зашифрованию, состоит в обратимом сокрытии статистических свойств открытого текста. При этом зашифровать можно и так, что шифротекст будет вполне себе «читаемым набором символов» – делов-то: «U2FsdGVkX1+yfyqjFLE8oJn5aokoCoaHwvd2UFW6lFO61I8B/nP+zA==» – все символы читаемые; можно вообще слова или фразы на естественном языке использовать. Сложно вычислить открытый текст, не зная подходящего ключа, это да.
Из опыта, основная проблема в том, что разработчики делают неверное обобщение и полагают, что можно обычным способом сравнивать значения переменных, имеющих тип float. То есть, дело не в сравнении конкретной записи – это сравнение определено как побитовое, и в стандарте оно строгое, детерминированное. Формально, два строгих float сравниваются точно. Но это не обобщается. Дело в том, что float – это не число, а некоторый алгоритм. Поэтому, концептуально, нужно сравнение понимать так, как если бы сравнивались алгоритмы.
Собственно, в статье примерно про это и написано:
Я бы только подчеркнул, что ни ассоциативность, ни дистрибутивность – не могут действовать "не точно", по определению. Поэтому-то и не нужно полагать, что эти свойства есть во float. Дистрибутивность, скажем, там не работает в совсем простых случаях – вот я недавно приводил пример: https://dxdt.ru/2025/08/31/16204/
Позволило-то – позволило, но вот больше года никто ничего не замечал подозрительного, в том числе и Cloudflare, которые являются оператором нескольких логов Certificate Transparency и предоставляют сервис мониторинга.
Всегда удивляет это утверждение. Компьютеры работают в подмножестве наутральных чисел, а вот ML - каким-то образом в
. Как такое возможно, если речь явно не про символьные вычисления, а большинство действительных чисел не получится даже записать в конечную память?
Вы что-то перепутали. В этом RFC нет рекомендации ставить для TLSA-записей разных сервисов CNAME на одно произвольное общее имя.
[Комментарий оказался не в той ветке.]
Всё ж, CNAME с разных номеров сервисов на единую нестандартную запись, да ещё с другим именем хоста в её составе, – не очень хорошая идея. Лучше бы публиковать индивидуальные TLSA под теми именами/номерами, к которым они относятся. (CNAME – вообще не очень хорошая штука, за очень редкими исключениями, а в паре с DNSSEC – так ещё хуже.)
Тут бы нужно предусмотреть период ожидания для замены серверного сертификата (rollover): то есть, выкатывать новую TLSA-запись для нового сертификата заранее, рядом со старой, а переходить на новый сертификат только после того, как истечёт TTL (лучше – два TTL) старой TLSA-записи; после перехода на новый сертификат – удалять TLSA-запись для старого.
Может быть и так, но тогда на стороне гипервизора возникнет проблема с тем, чтобы как-то согласовать результат разбиения чайника с результатами вычислений, которые, – опять же, внутри симуляции, – жители проводят на собственном суперкомпьютере. Если брать знаки записи π, то потом придётся «местное время» откручивать назад. Тоже, конечно, интересный вариант, но затратный.
Математика/логика – должны хотя бы сходиться на некотором подмножестве «законов», иначе и рассуждать-то о гипервизоре не получится.
Всё ж, если верить описанию методики на исходном сайте, то не на статистике поиска, а на «количестве упоминаний» в выдаче «систем поиска». А это количество упоминаний они определяют по показателю счётчика хитов, который вывела та или иная система в ответ на запрос.
Причём, к «системам поиска», согласно методике, относится и «поиск по сайту» на wikipedia.org, microsoft.com, amazon.com, ebay.com и др. - список опубликован. Ну, то есть, это даже не рейтинг по количеству статей, а рейтинг по счётчикам, выводимым в результатах обработки поискового запроса. Понятно, что Python нынче будет на первом месте, даже про ИИ можно и не упоминать.
Так уже в статье требуется, чтобы q было взаимно простым с основанием.
Это вряд ли из-за OCSP для LE. В их действующих TLS-сертификатах уже не должно быть ссылок на OCSP, а проверять отзыв для сертификата, у которого закончился срок действия, смысла нет (ну, разве что, вручную потестировать корректность настройки OCSP). Но, возможно, недоступна точка раздачи CRL.
Это тоже, согласен. С одной стороны, поток сертификатов увеличится и поддерживать OCSP станет ещё труднее; с другой стороны – TLS-сертификаты сейчас превращают в безотзывные кратковременные токены разрешения доступа пользователей, которые центральный сервис выдаёт узлам, публикующим веб-страницы и другую информацию, так что и OCSP, и CRL становятся технологической обузой.
Не нужно называть «шифрованием» процесс вычисления цифровой подписи – это неверно. Почему-то данная ошибка много лет кочует из статьи в статью. Подписывание – это совсем не «шифрование», это совсем другой процесс – и по назначению, и по логике применения, и по алгоритмам.
(Криптосистемы, кстати, называют «асиммметричными», не «асинхронными».)
Всё ж, информация и смысл - вещи разного уровня. В тексте может быть только один бит информации ("да/нет"), но очень и очень много смысла для конкретного читателя, а может - наоборот.
К сожалению, ни первый, ни второй вариант - совсем не передают структурных особенностей исходника на английском. Точно перевести невозможно.
Латынь, с её-то грамматикой, тут сильно способствует, так что не удивительно. В английском - посложнее.
Это есть и у Хомского, кстати. Но не понятно, в чём именно причина ограничения.
На картинке потерялся кусочек с "00.4e 25" -> "00.01 -1" <- "00.19 4a". А это как раз точки с уникальной Y-координатой.
Так как
- достаточно написать:
for k in range(1,4).А это всё потому, что 36 = 12 * 3.
Вот рисунок этой кривой над
:
Зелёным проведены прямые, на которых лежат точки с равными Y-координатами, таких точек, обычно, три. Две "потерявшихся" точки - (0x00, 0x4e) и (0x00, 0x19).
Вообще, так как в уравнении кривой справа кубика, а кривая - это группа, где, по определению сложения точек, A + B + C == O, то этим 111 точкам, при разбиении их на 12 подмножеств по 9 элементов (с остатком), со "сдвигами" в 63*G (63 == 3*3*7, GCD(111, 63) == 3), просто некуда будет деваться.
А так - в теории чисел сложно найти что-то более структурированное, чем эллиптические кривые.
Оно слишком знаменитое.