Если же решать в области комплексных чисел, то спокойно получаем два корня.
Что то я запутался ребята)
Я попробовал не сокращать sqrt(x), а, преобразовав уравнения, избавиться от радикала (возвел в квадрат обе части; вынес радикал отдельно; снова возвел). У меня получилось уравнение 8-й (ой!) степени:
а по основной теореме Алгебры (точнее следствие из нее) у него должно быть строго 8 корней. 2 действительных точно есть, осталось найти 6 комплексных.
Но что-то мне подсказывает, что я немного свернул не туда. Кто-нибудь подскажет, где я ошибся в рассуждениях? Буду благодарен. Прошу прощения, что не по теме.
Я имел в виду (как это называется?) прокси-работников. Они тебя как бы наняли; работаешь ты; но они за тебя получают деньги; тебе - часть. Где-то тут проскакивала схема (не могу найти). Я мельком тогда прочитал, не вникал. Как бы не L...soft этим балуется. Могу ошибаться. Вот меня и заинтересовало, как юридически это реализовать; и как распознать, что ты работаешь (или устраиваешься к) на посредника, делающего на тебе деньги.
Всё бы ничего, но где-то в миннауке усердно работают неугомонные люди, которые требуют подробную отчетность.
Это Вы прям в точку. А не пробовали по приколу делать фейковые отчеты с рандомными данными? Есть весомые подозрения, что их все-равно никто не смотрит.
кажешь 200 - ехидный HR из соседней конторы его заберёт, указав 220, в потом прогнёт до 160 с последующим ростом зарплаты за два года.
Немного непонятный момент. А не подскажите здесь - как это технически/юридически реализуется? И как таких вычислить? Не хотел бы нарваться на такого HR. Думаю, и многие хабровчане коллеги не хотели бы.
Ещё не хотелось бы нарваться на тех, кто будет делать на тебе деньги: ты будешь получать 60, он - 200. Здесь тоже интересно как эта схема работает, и хотелось бы от коллег услышать совета, как не нарваться на таких "чудил".
Да Вы правы, "хороший" - это больше из области вкусовщины. Кому-то нравится функциональный подход, кому-то - императивный. Кто-то любит циклы, кто-то рекурсии. И т.д. В этих ваших интернетах только и споры об этом.
По моему скромному мнению, новый ЯП, претендующий на статус "хорошего", обязательно должен впитать в себя все сильные стороны других ЯП, учитывать их опыт, и по максимуму нивелировать выявленные недостатки. Хочешь ручную работу памяти - пожалуйста; хочешь сборщик мусора - тоже. Хочешь строгих типов - используй. Хочешь сейчас писать без типов - пожалуйста. Не мешать опытному программисту писать потенциально опасный системный код, но помогать неопытному (и опытному тоже) не допускать типовых и серьезных ошибок.
Хороший ЯП не должен иметь конструкций или предъявлять каких-то требований, от которых большая часть программистов будет страдать. Не должно быть перекоса в какую-то одну область или парадигму. Синтаксис языка не должен сильно отличаться от мейнстрима и вызывать боль.
Новый современный ЯП должен быть универсальным: позволять писать как драйвера и компоненты ОС, так и простые сценарии для веб-страниц, компьютерных игр.
И это лишь малая часть требований к хорошему языку. Но как я уже сказал ранее: термин "хороший" сильно завязан на вкусы.
Если вы найдете еще какое-нибудь разумное практическое (не академическое) применение многозначной арифметики
Вычисления с большей точностью, чем 64-80-128 бит. Тот же BigDecimal в Java основан на BigInteger. Также (редко, но) встречаются задачи, когда целочисленные вычисления требуют разрядности большей, чем 64 бит. Например, 66 бит. И тип данных long уже не подходит.
Ну и из статьи не совсем понятно, что хотел от вас коллега: спросить алгоритм умножения, или о языковых средствах, реализующих работу с большими числами.
Что касается алгоритмов умножения/деления или быстрого возведения в степень. То я бы не сказал, что там всё так просто. Алгоритмов много. У каждого своя специфика. Один быстрый, но уязвимый к атакам по побочным каналам связи. Другой медленный, но стабильный.
Если вдруг вам будет необходим именно сумматор с ускоренным переносом
Не смею отвлекать по пустякам. У Вас и так задача грандиозная.
Просто тоже готовлю статью на Хабр про оптимизацию scrypt и имплементацию её на ASIC. Предварительно насчитал, сколько потребуется транзисторов на это. Но хотелось бы проверить себя.
Да именно про него. Но вообще, я хочу примерно прикинуть, сколько транзисторов уйдет на аппаратную реализацию SHA-256, если её развернуть в конвейер.
Если вы представляете, как из транзисторов реализовать каждый блок,
Представляю. Но, я любопытствующий дилетант. Поэтому хочу уточнить у более сведущих людей.
Коллеги, поправьте ход моих мыслей. Полагаю, что на AND уйдет 2 транзистора, на XOR - 6, на OR - это вроде вообще спариванием контактов можно реализовать. Смотрел здесь (кстати, весьма недурной симулятор).
И еще вопрос, почему так популярны элементы И-НЕ, ИЛИ-НЕ? Я что-то упустил этот момент.
Такого рода задачи легко решаются при помощи теории групп. Мало того, именно при помощи теории групп вы сможете доказать, что задача вообще имеет решение. Числа 5 и 3 взаимно просты, а значит вы легко сможете получить любое значение: 1, 2, 3, 4, 5 литров. А вот для комбинации 6, 3 получить 2 литра уже не получится. Попробуйте доказать это или опровергнуть самостоятельно.
И не нужно строить никаких гигантских таблиц и конечных автоматов. Яркий пример, когда знания математики программистам нужны.
Немного не по теме... А Вы не подскажите, сколько транзисторов уходит, на реализацию 32-битного сумматора двух чисел? Я руководствовался описанием отсюда https://ru.wikipedia.org/wiki/Сумматор_с_переключением_переноса и насчитал 854. Буду очень благодарен за справку.
Друзья, не подскажете какой лучше алгоритм выбрать для вычисления синуса с точностью до 200-300 бит (размер мантиссы). Входной аргумент: 0 <=x <1 в радианах. Может есть хорошие библиотеки по работе с вещественными числами настраиваемой точности (типа, хочешь 200 бит мантиссы - на тебе)? За совет буду благодарен. Или тут можно отделаться арифметикой с фиксированной запятой и работать с рациональным представлением чисел?
Если использовать ряд Тейлора, то не будет ли оптимальнее (для заявленной точности) вычислять sin(x/2) и cos(x/2)? Эти ряды, по идее, будут сходиться быстрее...
Простите, а где можно почитать про классическую арифметику? Про теорию чисел - читал, про теорию групп - читал, про алгебру тоже. А вот про арифметику...
Только для вычисления x. hash - это криптографическая хеш-функция, не scrypt. Сам scrypt, конечно же работает, на базе криптографической хеш-функции (SHA-2). Основное предназначение scrypt - сильно замедлить подбор пароля пользователя, по известной злоумышленнику соли и хешу. В остальных случаях, где нужен хеш - используется SHA-2; криптографы уже не рекомендуют использовать SHA-1.
Теническая ошибка. Я неявно допустил, что N выбрано 2048-битным (см. https://datatracker.ietf.org/doc/html/rfc5054#appendix-A, п. 3). Хотя об этом не сказал. Да, прошу прощения. Так что далее, подразумевается, что разрядность чисел A, B не может быть больше 2048 бит, т.к. мы получаем эти числа, как результат математических операций по модулю N. Что касается, исходных чисел a и b, - они должны иметь разрядность не менее 11 бит (миниальное точное значение необходимо уточнить у математиков; подразумеваю, что не менее 22 бит). Иначе задача дискретного логарифма превращается в просто задачу логарифма,
Можно сгенерировать под каждый проект/сайт индивидуально. Тогда сервер должен предварительно уведомлять клиента о использумых им N и g. Но учтите, что поиск больших простых чисел достаточно трудоёмкая операция. Можно неудачно сгенерировать N и получить уязвимость. Я же предлагаю не использовать индивидуальные N/g для каждого клиента, т.к. клиенту придется где-то хранить ещё и эти параметры для каждого сервера.
Незачем. Досадная ошибка. Я много раз вычитывал текст, перед публикацией. Но видно глаз замылился. Можно убрать отправку из п. 6.
N - 2048-битная. Тут нужно соблюсти баланс между достаточным уровнем безопасности и техническими накладками по реализации. Считаю (субъетивное мнение), что 2048 - это на текущий момент достаточная длина модуля. Более крупные модули приведут к тому, что числа (V, A, B) будут такими же крупными. Не будем забывать, что серверу придется хранить верификатор пользователя (V - 256 байт), а при аутентификации ещё и оперировать такими гиганскими числами. При такой математике впору подумать над защитой от DDoS. Основная уязвимость протокола SRP в том, что сервер делает гораздо больше вычислений, чем клиент при авторизации.
А вот не знаю, кто съел картинку) Когда публиковал статью - была. Формула там один-в-один как в п. 2, только соль вместо логина.
Большое спасибо за внимательное прочтение и вопросы "по делу".
К тому же, кто мешает в таком незащищённом соединении модифицировать ваши скрипты и передать пароль в открытом виде на сторону?
Вот поэтому я и предлагаю в новом протоколе (на базе SRP), вынести процессы авторизации (включая сопутствующие) за рамки "браузер-сервер", как сейчас работает TLS.
А Вы не могли бы вкратце пояснить, чем именно лучше? Я сейчас без подвохов спрашиваю.
Я погрузился в черновик стандарта OPAQUE, но так и не понял, выполняются ли нужные мне требования: взаимная аутентификация сторон, защита клиента даже после взлома сервера при последующем активном вмешательстве в канал (защита от проксирования, навязывания ложной информации).
Не увидел там формул вообще. А только поверхностное описание протокола при очень подробном описании используемых структур данных. Может не туда смотрел, каюсь заранее.
Утверждение, что "теория эллиптических кривых ещё только-только развивается", я не раз слышал от самих математиков на лекциях. Хотя теория такая, что приходится вгрызаться зубами, чтобы хоть что-то понять. Знал бы, что придется держать ответ, собирал бы пруфы.
Математики вообще скромные ребята: "мы только-только начертили дорожную карту, чтобы понять, куда идти дальше". Сравните со "здание физики уже построено, остались лишь детали".
Опасения о том, что "не все кривые одинаково полезны", тоже не на пустом месте родились. Особенно после известных в узком кругу скандалов.
Так что я тут "за что купил, за то и продаю") Не судите строго.
В протоколе, который проектирую, само явление "как ввод логина/пароля" на веб-сайте уходит "в отставку". Аутентификацию предлагается проводить через дополнительные HTTP-заголовки по протоколу SRP.
Сервер себя идентифицирует не по доменному имени (как это принято в SSL), а по идентификатору, который выбирает сам. Как результат, появляется понятие не сайта, а "приложения", которое может быть распределено по нескольким доменам, или, наоборот, несколько приложений (даже от разных вендоров) сконцентрироваться в пределах одного домена.
Конечно, в такой схеме любой сайт, заманивший пользователя к себе, может попытаться использовать чужой идентификатор и потребовать "авторизоваться" (аналог фишина в моей версии протокола). Но т.к. SRP требует от сторон взаимной проверки, сервер злоумышленника не сможет прикинуться легальным, и клиент это выявит (пп. 9-12 протокола).
Не получится и проксировать запросы через себя, подменяя информацию. Хотя прослушивать сможет. Но сам акт авторизации никак не выдает ключевую информацию, и уж тем более пароль. Обратите внимание, что там на первом этапе вообще передаются случайные числа, из которых получить исходный ключ или верификатор клиента невозможно, даже если решить задачу дискретного логарифма.
Кроме того, в дальнейшем полученный сессионный ключ предлагается использовать для подписи запросов клиента и сервера. Тем самым мешая проксирующему серверу "навязать" неверные данные.
Вообще, я предлагаю стандартизировать большинство процессов, связанных с аутентификацией (регистрация, замена ключей, логин/логаут, предоставление/отзыв доступов сторонним интернет-приложениям, резервный план восстановления учеток и другое), освободив разработчиков от это "рутины". Но это тема большой отдельной статьи.
Что то я запутался ребята)
Я попробовал не сокращать sqrt(x), а, преобразовав уравнения, избавиться от радикала (возвел в квадрат обе части; вынес радикал отдельно; снова возвел). У меня получилось уравнение 8-й (ой!) степени:
а по основной теореме Алгебры (точнее следствие из нее) у него должно быть строго 8 корней. 2 действительных точно есть, осталось найти 6 комплексных.
Но что-то мне подсказывает, что я немного свернул не туда. Кто-нибудь подскажет, где я ошибся в рассуждениях? Буду благодарен. Прошу прощения, что не по теме.
Я имел в виду (как это называется?) прокси-работников. Они тебя как бы наняли; работаешь ты; но они за тебя получают деньги; тебе - часть. Где-то тут проскакивала схема (не могу найти). Я мельком тогда прочитал, не вникал. Как бы не L...soft этим балуется. Могу ошибаться. Вот меня и заинтересовало, как юридически это реализовать; и как распознать, что ты работаешь (или устраиваешься к) на посредника, делающего на тебе деньги.
А так да, концептуально Вы правы.
Это Вы прям в точку. А не пробовали по приколу делать фейковые отчеты с рандомными данными? Есть весомые подозрения, что их все-равно никто не смотрит.
Немного непонятный момент. А не подскажите здесь - как это технически/юридически реализуется? И как таких вычислить? Не хотел бы нарваться на такого HR. Думаю, и многие хабровчане коллеги не хотели бы.
Ещё не хотелось бы нарваться на тех, кто будет делать на тебе деньги: ты будешь получать 60, он - 200. Здесь тоже интересно как эта схема работает, и хотелось бы от коллег услышать совета, как не нарваться на таких "чудил".
Да Вы правы, "хороший" - это больше из области вкусовщины. Кому-то нравится функциональный подход, кому-то - императивный. Кто-то любит циклы, кто-то рекурсии. И т.д. В этих ваших интернетах только и споры об этом.
По моему скромному мнению, новый ЯП, претендующий на статус "хорошего", обязательно должен впитать в себя все сильные стороны других ЯП, учитывать их опыт, и по максимуму нивелировать выявленные недостатки. Хочешь ручную работу памяти - пожалуйста; хочешь сборщик мусора - тоже. Хочешь строгих типов - используй. Хочешь сейчас писать без типов - пожалуйста. Не мешать опытному программисту писать потенциально опасный системный код, но помогать неопытному (и опытному тоже) не допускать типовых и серьезных ошибок.
Хороший ЯП не должен иметь конструкций или предъявлять каких-то требований, от которых большая часть программистов будет страдать. Не должно быть перекоса в какую-то одну область или парадигму. Синтаксис языка не должен сильно отличаться от мейнстрима и вызывать боль.
Новый современный ЯП должен быть универсальным: позволять писать как драйвера и компоненты ОС, так и простые сценарии для веб-страниц, компьютерных игр.
И это лишь малая часть требований к хорошему языку. Но как я уже сказал ранее: термин "хороший" сильно завязан на вкусы.
А вот интересно, вместе с обнулением кармы твои работы тоже удаляются: статьи, диалоги, комментарии?
Вычисления с большей точностью, чем 64-80-128 бит. Тот же BigDecimal в Java основан на BigInteger. Также (редко, но) встречаются задачи, когда целочисленные вычисления требуют разрядности большей, чем 64 бит. Например, 66 бит. И тип данных long уже не подходит.
Ну и из статьи не совсем понятно, что хотел от вас коллега: спросить алгоритм умножения, или о языковых средствах, реализующих работу с большими числами.
Что касается алгоритмов умножения/деления или быстрого возведения в степень. То я бы не сказал, что там всё так просто. Алгоритмов много. У каждого своя специфика. Один быстрый, но уязвимый к атакам по побочным каналам связи. Другой медленный, но стабильный.
Не смею отвлекать по пустякам. У Вас и так задача грандиозная.
Просто тоже готовлю статью на Хабр про оптимизацию scrypt и имплементацию её на ASIC. Предварительно насчитал, сколько потребуется транзисторов на это. Но хотелось бы проверить себя.
Да именно про него. Но вообще, я хочу примерно прикинуть, сколько транзисторов уйдет на аппаратную реализацию SHA-256, если её развернуть в конвейер.
Представляю. Но, я любопытствующий дилетант. Поэтому хочу уточнить у более сведущих людей.
Коллеги, поправьте ход моих мыслей. Полагаю, что на AND уйдет 2 транзистора, на XOR - 6, на OR - это вроде вообще спариванием контактов можно реализовать. Смотрел здесь (кстати, весьма недурной симулятор).
И еще вопрос, почему так популярны элементы И-НЕ, ИЛИ-НЕ? Я что-то упустил этот момент.
Такого рода задачи легко решаются при помощи теории групп. Мало того, именно при помощи теории групп вы сможете доказать, что задача вообще имеет решение. Числа 5 и 3 взаимно просты, а значит вы легко сможете получить любое значение: 1, 2, 3, 4, 5 литров. А вот для комбинации 6, 3 получить 2 литра уже не получится. Попробуйте доказать это или опровергнуть самостоятельно.
И не нужно строить никаких гигантских таблиц и конечных автоматов. Яркий пример, когда знания математики программистам нужны.
Тоже подписываюсь.
Немного не по теме... А Вы не подскажите, сколько транзисторов уходит, на реализацию 32-битного сумматора двух чисел? Я руководствовался описанием отсюда https://ru.wikipedia.org/wiki/Сумматор_с_переключением_переноса и насчитал 854. Буду очень благодарен за справку.
Друзья, не подскажете какой лучше алгоритм выбрать для вычисления синуса с точностью до 200-300 бит (размер мантиссы). Входной аргумент: 0 <=x <1 в радианах. Может есть хорошие библиотеки по работе с вещественными числами настраиваемой точности (типа, хочешь 200 бит мантиссы - на тебе)? За совет буду благодарен. Или тут можно отделаться арифметикой с фиксированной запятой и работать с рациональным представлением чисел?
Если использовать ряд Тейлора, то не будет ли оптимальнее (для заявленной точности) вычислять sin(x/2) и cos(x/2)? Эти ряды, по идее, будут сходиться быстрее...
Простите, а где можно почитать про классическую арифметику? Про теорию чисел - читал, про теорию групп - читал, про алгебру тоже. А вот про арифметику...
Только для вычисления x. hash - это криптографическая хеш-функция, не scrypt. Сам scrypt, конечно же работает, на базе криптографической хеш-функции (SHA-2). Основное предназначение scrypt - сильно замедлить подбор пароля пользователя, по известной злоумышленнику соли и хешу. В остальных случаях, где нужен хеш - используется SHA-2; криптографы уже не рекомендуют использовать SHA-1.
Теническая ошибка. Я неявно допустил, что N выбрано 2048-битным (см. https://datatracker.ietf.org/doc/html/rfc5054#appendix-A, п. 3). Хотя об этом не сказал. Да, прошу прощения. Так что далее, подразумевается, что разрядность чисел A, B не может быть больше 2048 бит, т.к. мы получаем эти числа, как результат математических операций по модулю N. Что касается, исходных чисел a и b, - они должны иметь разрядность не менее 11 бит (миниальное точное значение необходимо уточнить у математиков; подразумеваю, что не менее 22 бит). Иначе задача дискретного логарифма превращается в просто задачу логарифма,
Можно сгенерировать под каждый проект/сайт индивидуально. Тогда сервер должен предварительно уведомлять клиента о использумых им N и g. Но учтите, что поиск больших простых чисел достаточно трудоёмкая операция. Можно неудачно сгенерировать N и получить уязвимость. Я же предлагаю не использовать индивидуальные N/g для каждого клиента, т.к. клиенту придется где-то хранить ещё и эти параметры для каждого сервера.
Незачем. Досадная ошибка. Я много раз вычитывал текст, перед публикацией. Но видно глаз замылился. Можно убрать отправку из п. 6.
N - 2048-битная. Тут нужно соблюсти баланс между достаточным уровнем безопасности и техническими накладками по реализации. Считаю (субъетивное мнение), что 2048 - это на текущий момент достаточная длина модуля. Более крупные модули приведут к тому, что числа (V, A, B) будут такими же крупными. Не будем забывать, что серверу придется хранить верификатор пользователя (V - 256 байт), а при аутентификации ещё и оперировать такими гиганскими числами. При такой математике впору подумать над защитой от DDoS. Основная уязвимость протокола SRP в том, что сервер делает гораздо больше вычислений, чем клиент при авторизации.
А вот не знаю, кто съел картинку) Когда публиковал статью - была. Формула там один-в-один как в п. 2, только соль вместо логина.
Большое спасибо за внимательное прочтение и вопросы "по делу".
Вот поэтому я и предлагаю в новом протоколе (на базе SRP), вынести процессы авторизации (включая сопутствующие) за рамки "браузер-сервер", как сейчас работает TLS.
Так если бы своими руками давал. Вот в школах интернет "фильтруют" в принудительном порядке. Ровно таким методом.
А Вы не могли бы вкратце пояснить, чем именно лучше? Я сейчас без подвохов спрашиваю.
Я погрузился в черновик стандарта OPAQUE, но так и не понял, выполняются ли нужные мне требования: взаимная аутентификация сторон, защита клиента даже после взлома сервера при последующем активном вмешательстве в канал (защита от проксирования, навязывания ложной информации).
Не увидел там формул вообще. А только поверхностное описание протокола при очень подробном описании используемых структур данных. Может не туда смотрел, каюсь заранее.
Утверждение, что "теория эллиптических кривых ещё только-только развивается", я не раз слышал от самих математиков на лекциях. Хотя теория такая, что приходится вгрызаться зубами, чтобы хоть что-то понять. Знал бы, что придется держать ответ, собирал бы пруфы.
Математики вообще скромные ребята: "мы только-только начертили дорожную карту, чтобы понять, куда идти дальше". Сравните со "здание физики уже построено, остались лишь детали".
Опасения о том, что "не все кривые одинаково полезны", тоже не на пустом месте родились. Особенно после известных в узком кругу скандалов.
Так что я тут "за что купил, за то и продаю") Не судите строго.
Ох как хитро завернули, коллега! Я так и не понял, кто мсье, кто хочет оспорить, и кому посвящена ваша реплика. Но меня точно не стоит демотивировать)
Но судя по тому, что в приведенной Вами ссылке кривая Биткоина называется небезопасной, думаю,
Или я не прав?
Если я правильно понял Ваш вопрос.
В протоколе, который проектирую, само явление "как ввод логина/пароля" на веб-сайте уходит "в отставку". Аутентификацию предлагается проводить через дополнительные HTTP-заголовки по протоколу SRP.
Сервер себя идентифицирует не по доменному имени (как это принято в SSL), а по идентификатору, который выбирает сам. Как результат, появляется понятие не сайта, а "приложения", которое может быть распределено по нескольким доменам, или, наоборот, несколько приложений (даже от разных вендоров) сконцентрироваться в пределах одного домена.
Конечно, в такой схеме любой сайт, заманивший пользователя к себе, может попытаться использовать чужой идентификатор и потребовать "авторизоваться" (аналог фишина в моей версии протокола). Но т.к. SRP требует от сторон взаимной проверки, сервер злоумышленника не сможет прикинуться легальным, и клиент это выявит (пп. 9-12 протокола).
Не получится и проксировать запросы через себя, подменяя информацию. Хотя прослушивать сможет. Но сам акт авторизации никак не выдает ключевую информацию, и уж тем более пароль. Обратите внимание, что там на первом этапе вообще передаются случайные числа, из которых получить исходный ключ или верификатор клиента невозможно, даже если решить задачу дискретного логарифма.
Кроме того, в дальнейшем полученный сессионный ключ предлагается использовать для подписи запросов клиента и сервера. Тем самым мешая проксирующему серверу "навязать" неверные данные.
Вообще, я предлагаю стандартизировать большинство процессов, связанных с аутентификацией (регистрация, замена ключей, логин/логаут, предоставление/отзыв доступов сторонним интернет-приложениям, резервный план восстановления учеток и другое), освободив разработчиков от это "рутины". Но это тема большой отдельной статьи.