Вы выбираете два простых числа, p и q. Умножаете их и получаете n. Далее, вы выбираете простую публичную экспоненту e, которая будет шифрующей экспонентой, и специально подобранную обратную e, d, которая будет дешифрующей. Затем вы делаете n и e публичными и храните d в секрете. Про p и q можно забыть, или же хранить вместе с d.
Как мы уже убедились ранее, d получается из факторизации n обратно к p и q, что довольно-таки сложно.
Если быть точным, то пропущен немаловажный для RSA шаг (ну или 2):
1) выбираем 2 достаточно больших, примерно одного размера простых числа p и q.
2) перемножаем их, получаем n. 3) вычисляем функцию Эйлера для числа n, которая будет равна: Φ(n) = (p-1)(q-1), так как p и q — простые числа.
4) выбираем открытый ключ для шифрования e, который меньше Φ(n).
5) находим секретный ключ d для расшифрования, как обратный элемент e по модулю Φ(n), т.е. d = e^-1 (mod Φ(n)).
6) теперь можно забыть p,q, Φ(n), у нас есть все для дальнейшей работы.
:)
В коде у Вас он действительно меньше порядка подгруппы, образованной G. Но это ваш секретный ключ :)
Была бы это лаба студента, а я был бы проверяющим ее, то не удержался бы от того, чтобы попробовать ключик побольше))
А статья серия статей мне понравилась. Очень доступно излагаете, так держать, жду продолжения ;)
Может, я не до конца разобрался (признаюсь, код не запускал еще), но снова повторюсь. При просмотре кода я не заметил нейтрального элемента. Мы работаем в дискретном поле, и он нам нужен. Ведь существует ненулевая вероятность, что при какой-то итерации будет ситуация, в которой должно произойти сложение точек: P + (-P) =О
Исходя из теории, результатом должна стать как раз-таки особая точка. Аналогично для P + O = P.
Это, в принципе, можно было и не брать во внимание, если бы была оговорка, что секретный ключ d — это число меньше порядка подгруппы (n), образованной точкой G порождающим элементом G. Об этом, кстати говоря, в самом ГОСТе сказано. А в общем случае, ничто не мешает мне выбрать в качестве d случайное число и больше n, тогда подгруппа пробежит по всем элементам (включая О) и остановится где-то на «втором круге». Это не есть хорошо, так как секретный ключ будет небольшого порядка и может быть подвержен перебору. Так что ГОСТ рулит :)
Печатать полный номер карты на чеке тоже не разрешено. Первые 6 и последние 4 — можно.
Для проведения транзакции достаточно двух компонентов: PAN и EX.DATE. Все остальное — навороты для защиты.
Хранение полного номера карты (PAN) возможно с использованием:
— стойкого криптографического шифрования с налаженным процессом управления ключами;
— токенов (ссылок) — случайной строки, которая ставится в соответствие PAN. Таблица соответствия при это должно быть защищена (зашифрована), то есть PAN будут присутствовать только лишь в одном месте (причем, защищенном), а токены могут использоваться в информационной системе;
— хэш-функция. допускается хранение хэш-значений от PAN;
— маскирование — хранение первых 6 и последних 4 цифр от полного PAN.
При этом хранить одновременно хэш-значения и маски от одних и тех же PAN недопустимо, так как подобрать значения в этом случае не составит труда. К этому еще хочется добавить, что в принципе хранение хэш-значения несет в себе немалые риски, так как с текущим уровнем производительности вычислительных машин и сбором небольшой открытой информации о номере карты (имеется ввиду BIN карты) подбор полного номера осуществляется за полиномиальное время с очень небольшой степенью, независимо от применяемого протокола для вычисления хэш-функции.
Телефон неплохой. Камера для него — шикарна. Порой неожиданно приятно в действительно темной обстановке получить приемлемый кадр для домашнего фотоальбома. Видео смотрится очень приятно, тряска поглощается, и это заметно невооруженным глазом. Батарейку держит сутки, если пользоваться умеренно.
Это действительно хороший смартфон с чуть более, чем хорошей камерой для смартфона.
Имеется Canon 550D и lumia925. Зеркалка со съемной оптикой и другими прибамбасами хороша для запланированной фотосъемки (например, студийной или еще какой), 925 — для любой другой, когда важна память момента. С новым приложением ProCam (что на 1020 идет эксклюзивом и будет установлено по стандарту) появился и ручной фокус, и экспозиция и другие настройки. Не хватает регулировки диафрагмы. Но, надеюсь, в будущих версиях добавят.
В японском тогда омонимов будет очень много.
Кстати об омонимах. А как с ними будут обстоять дела в подобном словаре? Или это уже проблемы другого слоя — лексики?
Чтобы математически это доказать/опровергнуть нужно почитать книжек.
Векторное умножение… первой страницей в гугле выпала Вики, где векторным произведением будет перпендикуляр к плоскости… Отсюда пропадет замкнутость операции. Выходит, неприменимо для EC.
Алиса (А) придумывает число Na
Боб (B) придумывает число Nb
Стороны согласовывают параметры протокола (открытые).
А -> B следующее сообщение: Na*G
B -> A следующее сообщение Nb*G
А умножает Na*(Nb*G) = Na*Nb*G
B умножает Nb*(Na*G)=Na*Nb*G
Вуа-ля. Общий секретный ключ. Вычислить Na и Nb — равносильно разрешению трудноразрешимой задачи о нахождении дискретного логарифма в поле EC.
Я это себе так представлял :)
Хотя, возможно, где-то и просчитался.
Что-то либо я не понимаю, либо у Вас изначально неправильный посыл.
n1 — будет точкой EC.
Операции <точка>*<точка>=<число> в поле EC нет. Есть только <точка>+<точка>=<точка> и <число>*<точка>=<точка>.
Тема действительно очень интересная, много чего в ней есть для исследований.
Меня, когда я пытался реализовать протокол криптографический с использованием EC в учебных целях, сбило с толку, что нет заведомо быстрых алгоритмов по подсчету (генерации) точек эллиптической кривой. Преподаватель меня направил в сторону алгоритма Чуфа для расчета точек EC, но там в описании все довольно сложно. Может, кто знает какие быстрые способы для генерации точек EC (со словарным описанием)? Может, модули нужно по особому генерить, чтобы знать наверняка количество точек?
p.s. Конечно можно (а, скорее всего, лучше) использовать кривые, опубликованные в стандартах. Все-таки их свойства проверены должны быть, но для практики хотелось бы свою кривую получить :)
а как же особая точка «О»? Про нее даже упоминания нет в статье, а это нейтральный элемент как никак :)
Без него бы не было все так математически красиво.
Согласен. Чаще всего ошибка таится в реализации. А для асимметрического протокола на трудноразрешимых задачах стойкость доказана практикой. Ну подойдет вычислительная мощность и что, на 1024 бита параметры увеличат и снова можно лет 50 пользоваться. А для эллиптических кривых так вообще есть куда расти в этом плане. Там, вроде как, проблема только при шифровании (биекция алфавита и точек), но пусть шифрование самих данных так и остается на симметричных протоколах с доказуемой стойкостью :)
Про уши точно подмечено)
Уже так и вижу будущее, в котором наши внуки и правнуки будут в IKEA или еще каком-нибудь магазине покупать домашнюю утварь и аксессуары, обращая внимания на ценники, в которых будет указана совместимость ОС каждого изделия с платформой самого дома/квартиры.
А часики-то интересные. Действительно, узнать бы, какова начинка и функционал…
Если быть точным, то пропущен немаловажный для RSA шаг (ну или 2):
1) выбираем 2 достаточно больших, примерно одного размера простых числа p и q.
2) перемножаем их, получаем n.
3) вычисляем функцию Эйлера для числа n, которая будет равна: Φ(n) = (p-1)(q-1), так как p и q — простые числа.
4) выбираем открытый ключ для шифрования e, который меньше Φ(n).
5) находим секретный ключ d для расшифрования, как обратный элемент e по модулю Φ(n), т.е. d = e^-1 (mod Φ(n)).
6) теперь можно забыть p,q, Φ(n), у нас есть все для дальнейшей работы.
Боб — негласный общепринятый мировой стандарт)
В коде у Вас он действительно меньше порядка подгруппы, образованной G. Но это ваш секретный ключ :)
Была бы это лаба студента, а я был бы проверяющим ее, то не удержался бы от того, чтобы попробовать ключик побольше))
А
статьясерия статей мне понравилась. Очень доступно излагаете, так держать, жду продолжения ;)Исходя из теории, результатом должна стать как раз-таки особая точка. Аналогично для P + O = P.
Это, в принципе, можно было и не брать во внимание, если бы была оговорка, что секретный ключ d — это число меньше порядка подгруппы (n), образованной
точкой Gпорождающим элементом G. Об этом, кстати говоря, в самом ГОСТе сказано. А в общем случае, ничто не мешает мне выбрать в качестве d случайное число и больше n, тогда подгруппа пробежит по всем элементам (включая О) и остановится где-то на «втором круге». Это не есть хорошо, так как секретный ключ будет небольшого порядка и может быть подвержен перебору. Так что ГОСТ рулит :)Для одного значения подбор проходит очень быстро)
А так Вы правы, константа. Спасибо =)
Для проведения транзакции достаточно двух компонентов: PAN и EX.DATE. Все остальное — навороты для защиты.
— стойкого криптографического шифрования с налаженным процессом управления ключами;
— токенов (ссылок) — случайной строки, которая ставится в соответствие PAN. Таблица соответствия при это должно быть защищена (зашифрована), то есть PAN будут присутствовать только лишь в одном месте (причем, защищенном), а токены могут использоваться в информационной системе;
— хэш-функция. допускается хранение хэш-значений от PAN;
— маскирование — хранение первых 6 и последних 4 цифр от полного PAN.
При этом хранить одновременно хэш-значения и маски от одних и тех же PAN недопустимо, так как подобрать значения в этом случае не составит труда. К этому еще хочется добавить, что в принципе хранение хэш-значения несет в себе немалые риски, так как с текущим уровнем производительности вычислительных машин и сбором небольшой открытой информации о номере карты (имеется ввиду BIN карты) подбор полного номера осуществляется за полиномиальное время с очень небольшой степенью, независимо от применяемого протокола для вычисления хэш-функции.
Это действительно хороший смартфон с чуть более, чем хорошей камерой для смартфона.
Имеется Canon 550D и lumia925. Зеркалка со съемной оптикой и другими прибамбасами хороша для запланированной фотосъемки (например, студийной или еще какой), 925 — для любой другой, когда важна память момента. С новым приложением ProCam (что на 1020 идет эксклюзивом и будет установлено по стандарту) появился и ручной фокус, и экспозиция и другие настройки. Не хватает регулировки диафрагмы. Но, надеюсь, в будущих версиях добавят.
Кто, простите (О_о)>?
Поддерживаю Alex_SmartGadget.
Кстати об омонимах. А как с ними будут обстоять дела в подобном словаре? Или это уже проблемы другого слоя — лексики?
Векторное умножение… первой страницей в гугле выпала Вики, где векторным произведением будет перпендикуляр к плоскости… Отсюда пропадет замкнутость операции. Выходит, неприменимо для EC.
Боб (B) придумывает число Nb
Стороны согласовывают параметры протокола (открытые).
А -> B следующее сообщение: Na*G
B -> A следующее сообщение Nb*G
А умножает Na*(Nb*G) = Na*Nb*G
B умножает Nb*(Na*G)=Na*Nb*G
Вуа-ля. Общий секретный ключ. Вычислить Na и Nb — равносильно разрешению трудноразрешимой задачи о нахождении дискретного логарифма в поле EC.
Я это себе так представлял :)
Хотя, возможно, где-то и просчитался.
n1 — будет точкой EC.
Операции <точка>*<точка>=<число> в поле EC нет. Есть только <точка>+<точка>=<точка> и <число>*<точка>=<точка>.
Меня, когда я пытался реализовать протокол криптографический с использованием EC в учебных целях, сбило с толку, что нет заведомо быстрых алгоритмов по подсчету (генерации) точек эллиптической кривой. Преподаватель меня направил в сторону алгоритма Чуфа для расчета точек EC, но там в описании все довольно сложно. Может, кто знает какие быстрые способы для генерации точек EC (со словарным описанием)? Может, модули нужно по особому генерить, чтобы знать наверняка количество точек?
p.s. Конечно можно (а, скорее всего, лучше) использовать кривые, опубликованные в стандартах. Все-таки их свойства проверены должны быть, но для практики хотелось бы свою кривую получить :)
Без него бы не было все так математически красиво.
Про уши точно подмечено)
А часики-то интересные. Действительно, узнать бы, какова начинка и функционал…