• Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0

    Я не говорил, что это проблема только Python — только о том, что и в Python она тоже есть.

  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0

    Эта статья с моей формулой, к которой также приложены доказательства. Мои доказательства очень неэлегантны, и, возможно, повторны. Поэтому мне и интересно получить более элегантные доказательства или ссылки на существующие.

  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    Хорошо, если всё-таки у вас нет времени на доказательство, то продолжу надеется, что сюда зайдет «настоящий математик» и покажет какое-то более элегантное доказательство, чем моё.
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    Ну вот, а говорили, что на Хабре математиков нет :) Кстати, вы же вроде говорили, что это всё уже давно известно. Или всё-таки что-то новое придумали?
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    Вы сами эту формулу придумали или всё-таки где-то существующую нашли? Если нашли, то укажите хотя бы источник.
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    Приведите, пожалуйста, доказательства вашей формулы — мне сама формула интересна мало, гораздо более интересно как именно она выводится.
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    Кстати, скорее всего ваша погрешность возникла из-за внутренних «проблем» представления чисел на Python.
    print(1.2 + 1.2 + 1.2) #3.5999999999999996
    print(3*1.2) #3.5999999999999996
    

    Именно для устранения таких псевдо-погрешностей я использовал в своём проверочном коде специализированную библиотеку.
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    Нет, вы неправильно поняли: мне действительно интересно получить какие-то общие формулы, как-либо связанные с моей. Я очень даже предполагаю, что нечто подобное уже существует.

    Насчёт интерполяционных многочленов: в первом же комментарии к данной статье это и было сказано. Там же есть и возражения. Если есть что-то добавить — пожалуйста, добавьте в ту ветку. Насчёт формулы по ссылке: там, как минимум, есть ограничение по величине «шага» — от нуля включительно до единицы включительно. И в настоящий момент я затрудняюсь из этой формулы получить какой-то «частный случай», который бы давал формулу, которая есть у меня. Если вы видите как из формулы по вышей ссылке получить мою — буду благодарен за разъяснения.
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    У меня нет понятия «разностная схема». Можете привести некую обобщённую формулу для полинома произвольной степени, частным случаем которой является моя формула?
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0

    Можете пояснить в чём смысл вашего комментария?

  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    На самом деле по приведённой ссылке точки взяты именно равноотстоящие, только там шаг не 1, а 0.75. Мне сложно оценить какой метод лучше. Пусть каждый выбирает сам.
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    В случае произвольных точек для определения всего полинома вам понадобится (n+1) пар (x_i, y_i): только в этом случае вы сможете однозначно определить все множители при степенях полинома. В случае же конечных разностей понадобиться только (n+1) значений y_i, значения x_i не важны. Ну а в общем случае, конечно, через (n+1) точек может быть проведён только один полином степени n.
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    0
    На самом деле я довольно долго сомневался в необходимости публикации моих выводов. У меня были очень большие сомнения, что к подобным выводам не пришёл никто до меня. Однако в приведённой статье из Википедии приведены совершенно идентичные формулы и даже сказано «These identities may be proved in a number of ways...», но ни одного доказательства или хотя бы указания на возможный источник, где есть доказательство, не приводится. Я ещё поищу в данном направлении, спасибо за наводку.
    Собственно, вот и все доказательство

    А можно как-то по-подробнее — возможно и у меня получиться упростить свой вариант доказательства.
    Это тривиальное следствие...

    Эм, и как это тривиально доказать?
    Практическое применение этой формулы довольно узкое

    На самом деле подобные моим формулы используются уже очень давно и, на мой взгляд, достаточно широко. В основном в приложениях интерполяции/экстраполяции данных. Также при шаге стремящемся к нулю получаем приложение данных формул к вычислению интегралов фигур.

    На самом деле целью публикации данной статьи в основном являлось получение какой-либо возможной дополнительной информации по этой тематике. Самостоятельно ничего подобного я не нашел. Доказательств моих формул где либо в литературе нет, выводов, подобных сделанным мною я тоже не нашел. По вашей ссылке приведены правильные формулы, однако доказательств там тоже нет. Кроме основной цели также было интересно донести до читателей Хабра интересные факты про полиномы — оказывается их можно полностью определить по (n+1) равноотстоящим точкам и т.д.
  • Представление произвольных полиномов в виде конечных разностей с произвольным шагом
    +1

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

  • Свободные библиотеки для создания и редактирования файлов PDF
    +1

    И у меня в настоящий момент только RSA, ГОСТа пока нет. Но в целом я понял, что есть потребность в библиотеке подписи PDF в браузере. И даже в таком сыром виде как она есть сейчас. Поговорю с заказчиком — может откроем существующий код и продолжим дорабатывать его уже в открытом виде.

  • Свободные библиотеки для создания и редактирования файлов PDF
    0
    А в тете просто ужасно сырые данные. Вы познакомитесь со всей внутренней кухней пдф, структурами хранения и трансформациями над изображениями и он заставит вас все это делать ручками ибо изображение он достанет из ресурсов и отдельно матрицу трансформации. А если вдруг вы встретили тифф изображение, то он вам и его разберет на куски.

    Вот у меня примерно такая же библиотека — максимально низкоуровневые данные. Можно сделать «helpers» для всяких там добавлений текста и прочая, но эта библиотека создавалась для задачи минимального апдейта существующего документа, создания подписей (вплоть до PAdES LTV), шифрования/расшифрования документов. Красивости и «плюшки» не предусматривались. Вам нужна такая библиотека? И, кстати говоря, под какие именно задачи?
  • Свободные библиотеки для создания и редактирования файлов PDF
    +3

    Почти 4 года назад написал библиотеку на JS для разбора, создания любых pdf, а также для создания и проверки подписей. Однако пока код закрыт заказчиком. Написан большой сервис типа DocuSign. Кому-нибудь такая библиотека пригодилась бы?

  • ArrayBuffer и SharedArrayBuffer в JavaScript, часть 3: гонки потоков и Atomics
    0
    Языки никогда не развиваются в сторону уменьшения возможностей

    Я отвечал на это утверждение.
  • ArrayBuffer и SharedArrayBuffer в JavaScript, часть 3: гонки потоков и Atomics
    0
    TypeScript сейчас очень популярен и считается «развитием JavaScript». Вот вам и ответ.
  • ArrayBuffer и SharedArrayBuffer в JavaScript, часть 3: гонки потоков и Atomics
    0
    Правильно, ещё и строгую типизацию из TypeScript подтащить и сделать обязательной.
  • ArrayBuffer и SharedArrayBuffer в JavaScript, часть 3: гонки потоков и Atomics
    –2

    Когда уже заменят этот костыль под названием JavaScript на полноценную поддержку С++? И объекты в JS ввели, и уже про атомарность операций заговорили. Скоро ещё темплейты запилят и назовут JS++.

  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    УЖАС!

    Сертификаты выдаются удостоверяющим центром. И даже если LDAP и удостоверяющий центр были бы в руках одного администратора (таких примеров из реальной жизни у меня нет), то выпуск нового сертификата отражается в логах, увеличивается номер текущего сертификата и так далее. Все удостоверяющие центры проходят аудиты безопасности с различных сторон и так далее. Также для каждого удостоверяющего центра делается «модель угроз и нарушителя», где одной из основных угроз учитывается человеческий фактор обслуживающего персонала. И с предотвращением этой угрозы очень плотно работают.

    Вы всё-таки почитайте на досуге про PKI (Public-Key Infrastructure) — много нового для себя узнаете.
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Давно сюда не заходил.

    4. LDAP — использовать можно. Но это — централизованое хранилище, со всеми присущими ему недостатками. Например таким, что хозяин сервера волюнтаристки заменит мой сертификат в своей базе и пойдёт по всем моим акаунтам шарить.

    Вы вообще представляете, что именно хранится в LDAP, а что на клиентской машине, у самого пользователя? LDAP это хранилище публичных данных (например публичных ключей). Для того, чтобы «шарить во вашим аккаунтам» необходим ещё и закрытый ключ, которого в LDAP нет (по-умолчанию).
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Ну давайте ещё с вами пообсуждаем «банальные формальности», приводите примеры.
  • Алгоритм Deflate на примере формата PNG
  • Защищенные социальные сети — миф или реальность?
    0
    К сожаление в HTML5 нет встроенных механизмов шифрования

    В общем-то есть, хотя и в статусе «W3C Candidate Recommendation». Как вариант замены Forge могу предложить библиотеку написанную мной — PKIjs.

    А насчет построенной схемы обмена сообщениями: схема впринципе рабочая, однако возможны мелкие проблемы. Так, например Forge для PKCS#12 (да и для шифрования PKCS#8 ключей) использует устаревшие схемы генерации ключа на основе пароля. Сразу скажу, что пока в PKIjs отсутствует поддержка PKCS#12 и поддержка зашифрованных приватных ключей.
  • ASN1js и PKIjs — год после создания
    0
    В работе сейчас следующие части:
    • Работа с CAdES (создание всех версий, вплоть до архивных);
    • Работа с PAdES (подпись и шифрование). То есть PKIjs используется как вспомогательная в дополнение к нашему собственному парсеру/мейкеру PDF (всё на чистом JavaScript);
    • Создание собственных серверов OCSP, TSP, CA, RA (на Node.js);
    • Создание «polyfills» для возможности работы PKIjs с помощью сторонних библиотек таких как эта, а также для работы внутри Node.js, для работы с алгоритмами ГОСТ и прочая без изменения исходного кода PKijs;
    • Реализация полноценной «verification engine», способной проверять подписи CAdES и PAdES;
    • Реализация поддержки PKCS#12 (когда у меня будет время);
    • И ещё кое-что;

    Также скажу что понятие «в работе» фактически можно свести к «в работе на финальной стадии», то есть процентов 90 всего кода уже готово. Скорее всего весь код будет публично доступен, но часть его будет «только для некоммерческого использования». Следите за анонсами.

    Так что ресурсы вкладываются большие, библиотека активно совершенствуется, пусть пока и несколько скрытно.
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Наш диалог мне всё больше напоминает вот эту цитату с bash.im.

    Понимаете, давным-давно жили умные люди. И захотелось им чтобы было общее хранилище для всех цифровых идентификаторов пользователей. И придумали они стандарт X.500 — и возрадовались. Также были другие умные люди, которые решили, что стандарт X.500 уж больно сложен. И придумали они LDAP (Lightweight Directory Access Protocol), который был проще. Также умные люди придумали ещё один стандарт — X.509, дабы служил он для достоверной передачи сведений о пользователях и достоверной идентификации оных.

    А потом, лет эдак через 20, появился чудесный продукт — EMCSSL. И придумали для этого продукта базу данных — «доверенный блокчейн». И хранила она пары «имя-значение» и были эти пары однозначно привязаны к пользователю. С сертификатами в этом продукте решили не заморачиваться, и использовали сильно обрезанные сертификаты из X.509.

    А теперь по существу. Вашему «доверенный блокчейну» даже до упрощённых реализаций «X.500 directory» — как до Луны пешком. Все ваши «инновации» и «улучшение SSL» достигаются просто дополнительным уровнем проверки по вашей базе данных («доверенному блокчейну»). Всё это давным-давно возможно, и может быть реализовано гораздо более правильно путём использования стандартных «directories» с доступом по LDAP. Ваши «сертификаты» ущербны потому, что в них отсутствует корректное использование следующих полей:
    1) subject;
    2) notBefore + notAfter;
    3) issuerUniqueID + subjectUniqueID;
    4) ну и на сладкое — все поля из «extensions»;

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

    Кстати — полей «OU1...OU4» в сертификатах нет. Полагаю, что вы говорите про «organizationalUnitName», а это всего лишь один из элементов имени, используемый в полях сертификата «issuer», «subject» плюс в различных расширениях сертификата (поле «extensions»).

    У меня есть куча других дел, кроме копания в вашей поделке. Если мои замечания для вас пустой звук, то мне на самом деле наплевать. Мои замечания здесь тогда будут оценивать другие читатели данной статьи.
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Также в вашей системе возможна ситуация, когда пользователь изготавливает себе сертификат удостоверяющего центра. И таким образом может начать сам устанавливать политики использования выпущенных сертификатов и другие ограничения. Или сделать очень длинную цепочку сертификатов (скажем в 1000 промежуточных удостоверяющий центров) и создавать тем самым возможные проблемы для «certificate verification engines».

    Кстати, ответьте, пожалуйста, на мой вопрос в этой теме.
  • EMCSSL – Система идентификации пользователей WWW на основе подсистемы NVS криптовалюты EmerCoin и децентрализованных клиентских SSL-сертификатов
    0
    Вы публикуете (либо обновляете) «цифровую подпись» сертификата в EmerCoin NVS

    Обновляете? Это как?
    При генерации последующих сертификатов, Вы можете отредактировать файл *.tpl, и внести туда другие значения полей CN/Email/UID, после чего сгенерировать новый сертификат, заменить его в браузере и соответственно изменить контрольную сумму в соответствующей записи в NVS

    Правильно ли я понимаю, что можно произвольно заменять сертификаты просто зная его серийный номер?
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Ну тогда я вам расскажу, как работает ваша система. Всё работает по стандартной схеме PKI: есть один удостоверяющий центр и множество пользовательских сертификатов. Так как сертификат пользователя генерируется самим пользователем, то возникает проблема — отсутствие уникальности серийных номеров сертификатов. Данную проблему вы решаете использованием блокчейна. Так что блокчейн у вас тут крайне второстепенная вещь, которая просто обеспечивает формальные требования к пользовательским сертификатам. Доверенное TLS у вас действительно возникает, но вот только потому, что вы добавляете корневой сертификат вашего так сказать «удостоверяющего центра» в доверенные. То есть выполняете формальные требования.

    Однако думаю, что возможны различные претензии к вашим пользовательским сертификатам, вызванные тем, что генерируются они самим пользователем. Так основная претензия будет к качеству генерируемых ключей — при генерации ключей с помощью УЦ возможно использование «правильных алгоритмов» генерации и правильных параметров к ним, а вот при генерации на стороне пользователя с этим уже могут возникнуть сложности. Ну и опять же я до сих пор утверждаю, что в ваших сертификатах полезной нагрузкой является только публичный ключ. На все остальные поля сертификата можно закрывать глаза.
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Так каким образом у вас доверие к сертификату то возникает?
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Мда. Самоподписанным называется сертификат, у которого поля «issuer» и «subject» являются одинаковыми и у которого подпись самого сертификата выполнена с использованием закрытого ключа, соответствующего публичному ключу из данного сертификата. А ваша схема уже формально использует «удостоверяющий центр».
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Доверенный сертификат или нет в PKI определяется доверием к корневому сертификату цепочки сертификатов для данного пользовательского сертификата. Понятие «доверенный блокчейн» мне понятно слабо. Как я понял из статьи этот блокчейн может однозначно подтвердить только то, что серийный номер сертификата уникален.
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Так сертификат пользователя самоподписанный или нет?
  • Обзор Certificate Transparency
    +1
    Сервера логов СТ известны и эти сервера множатся. Однако вот знает ли кто-нибудь действующие сервера типа «аудитор» и «наблюдатель»? И вообще — насколько реальна задача в реальном времени проверить один сертификат по базе в 6-9 миллионов сертификатов?
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    У вас в статье есть вот такое выражение:
    Сервер, получив сертификат, вначале проверяет подпись сертификата. Успешная проверка подписи доказывает, что сертификат был сгенерирован для системы emcssl.

    Как сервер проверяет, что именно этот сертификат был сгенерирован для системы emcssl, при условии, что клиентский сертификат самоподписанный?
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Безопасное TLS соединение создаётся когда сертификат является доверенным. Ваши же сертификаты являются самоподписанными и доверенными их считать изначально невозможно. Для осуществления установления доверия к подобным сертификатам нужно будет провести очень большой комплекс процедур. И пока я считаю, что этот «комплекс процедур» будет существенно больше по затратам, чем стандартная модель PKI.
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    В общем ещё раз — в данной системе используется простейший режим создания подписей на основе уникальности пары «публичный-закрытый ключ». Сертификаты тут использованы только для того, чтобы упростить их использование в браузере. Из всего сертификата используется только массив публичного ключа. Какое-либо использование подобных «сертификатов» в PKI просто невозможно.
  • Беспарольная авторизация и другие неявные возможности цифровых сертификатов
    0
    Ах вот оно что — сертификаты самоподписаные. Тогда тем более нет никакой (вообще) причины использовать именно сертификаты. Если у вас возникает проблема с использованием публичного/приватного ключа при создании коммуникаций в браузере, то вполне вероятно написать самостоятельное расширение.