id: Гость   вход   регистрация
текущее время 07:42 18/11/2017
Автор темы: alexor1234, тема открыта 14/03/2016 22:11 Печать
Категории: криптография
https://www.pgpru.com/Форум/Криптография/МожноЛиИспользоватьТакиеИсточникиДляКодаСеанса
создать
просмотр
ссылки

Можно ли использовать такие источники для кода сеанса?


На сайте был вопрос про альтернативные источники для создания кода сеанса:
http://www.cyberforum.ru/crypt.....y/thread1678074.html


Вместо использования аппаратного генератора СЧ, наподобие RdRand, предлагается использовать время запуска программы по системному времени UTC, время запуска программы ещё по времени работы ПК (высокоточный таймер), и номер текущего сеанса.


Аппаратный ГСЧ не устроил автора за его не повсеместное распространение и за внешнюю зависимость.


Всё это даёт 24 байта кода сеанса.


Утверждается, что он никогда не совпадёт в пределах того же ПК, если только время не откатится слишком сильно назад (превышающее время запуска ОС), и то вероятность совпадения всё также мала.


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


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


 
На страницу: 1, 2 След.
Комментарии
— SATtva (16/03/2016 09:40)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046
Какая уважительная причина заставила автора заниматься столь унылым велосипедостроением вместо использования /dev/urandom?
— alexor1234 (16/03/2016 12:37, исправлен 16/03/2016 12:38)   профиль/связь   <#>
комментариев: 13   документов: 4   редакций: 1
Какая уважительная причина заставила автора заниматься столь унылым велосипедостроением вместо использования /dev/urandom?

Наверно желание самому контролировать процесс. Однако вещь довольно таки любопытная, и походу дела всё упирается в поддержание точного системного времени для теоретического несовпадения. Чтобы не было совпадений на разных ПК используется MAC адрес, но так ли физический адрес уникален, как считается?
То что это велосипедостроение было давно понятно, автору нравится это, вопрос лишь в том, как у него это получается.

— гыук (16/03/2016 13:04, исправлен 16/03/2016 13:04)   профиль/связь   <#>
комментариев: 261   документов: 0   редакций: 0

Не совсем по теме, но есть вопрос.
Пытаюсь запустить точку доступа на debian7 с помощью hostapd. При попытке запуска происходит завис на том, что не хватает энтропии /dev/random. Где прописать чтобы обращение шло в /dev/urandom?

— SATtva (17/03/2016 10:17)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Почему бы тогда не подбрасывать монетку?


Он и не считается уникальным. В нём в лучшем случае 64 бита данных, значительная часть из которых вообще предсказуемы: идентификатор изготовителя, идентификатор типа и модели устройства и т.д. (Задача MAC-адреса в том, чтобы быть уникальным, а не случайным.) Но главное в том, что MAC-адрес не является сколь-нибудь секретным, он всегда передаётся в сеть и всегда в открытом виде.
— гыук (17/03/2016 13:09)   профиль/связь   <#>
комментариев: 261   документов: 0   редакций: 0

Добавлю, и легко подменяем.
— alexor1234 (17/03/2016 14:20, исправлен 17/03/2016 14:29)   профиль/связь   <#>
комментариев: 13   документов: 4   редакций: 1

У автора выбор стоит, либо пропускать ключ, MAC адрес и время запуска программы по двум таймерам (utc, hightimer) через хеш-функцию, либо не пропускать, но если не пропускать через хеш, то смущает раскрытие посторонним время запуска и самого MAC адреса, так ли это страшно?, тем более что с приходом IPv6, где последние 64 бита – это и есть физический адрес, его раскрытие неизбежно.
Но повторюсь, у автора цель с помощью всего этого получить только лишь неповторимую числовую последовательность для кода сеанса.
Я например, даже не могу сказать, какой вариант мне больше нравится, так как пропускание всего этого через хеш может дать теоретическую коллизию, хотя наверно при достаточно большой длине это в принципе не должно волновать и может быть аргументом только в теории, но не в практике.

— alexor1234 (18/03/2016 20:11, исправлен 19/03/2016 01:15)   профиль/связь   <#>
комментариев: 13   документов: 4   редакций: 1

Автор решился и выбрал второй вариант, с небольшими изменениями:
ID – идентификатор юзера в случае многопользовательского подключения
Key – секретный ключ юзера
"1" – режим работы – генерация кода сеанса
PhysicalAddress[1...16] – физические MAC адреса (6 байт) шестнадцати и не более интерфейсов, если их меньше, оставшиеся байты массива остаются нулевыми.
TimeLaunch_UTC – время запуска программы по UTC
TimeLaunch_HighTimer – время запуска программы по высокоточному таймеру работы ПК
NumberSeance – номер текущего кода сеанса (инкремент +1)


Код сеанса равен как SHA-3-512(ID & Key & 1 & PhysicalAddress[1] & ... & PhysicalAddress[16] & TimeLaunch_UTC & TimeLaunch_HighTimer & NumberSeance).


Совпадения кодов сеанса начнутся после 2^256 сгенерированных кодов в пределах одного и того же юзера или же после 2^192 при вероятности 1 к 2^128 (2^(512-192*2)=2^128), что похоже успокоило автора.


Ну вобщем-то конечно способ достаточно интересный.


Как я понял, несколько MAC-адресов нужны, чтобы случайно не нарваться на неликвидный, как например у Teredo или других виртуальных адаптеров.

— SATtva (19/03/2016 12:11)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Автор ставит ошибочную дилемму. Нет никакой разницы, хэшируются входные данные ГПСЧ или нет, если сами входные данные предсказуемы или их можно достаточно быстро перебрать.


Что такое "код сеанса"? Nonce для криптопараметров? Или просто какой-то случайный идентификатор для сессии пользователя на веб-сайте?
— alexor1234 (19/03/2016 19:26, исправлен 19/03/2016 19:27)   профиль/связь   <#>
комментариев: 13   документов: 4   редакций: 1
, если сами входные данные предсказуемы или их можно достаточно быстро перебрать.

Как я понял, это сделать не получиться, потому что на вход подаётся секретный ключ Key. Входные данные хешируются, потому что автор не хочет их раскрывать посторонним.


Что такое "код сеанса"? Nonce для криптопараметров? Или просто какой-то случайный идентификатор для сессии пользователя на веб-сайте?

Как я понял, это просто идентификатор сессии, чтобы выходная гамма была каждый раз разной.

— SATtva (20/03/2016 09:19)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

И мы возвращаемся к первому вопросу: зачем этот странный велосипед, если можно использовать стандартную конструкцию HMACk(R), где R — вывод из /dev/urandom?
— alexor1234 (20/03/2016 16:21, исправлен 20/03/2016 16:26)   профиль/связь   <#>
комментариев: 13   документов: 4   редакций: 1
И мы возвращаемся к первому вопросу: зачем этот странный велосипед, если можно использовать стандартную конструкцию HMACk®, где R — вывод из /dev/urandom?

Автору не нравится натуральный (аппаратный) ГСЧ вот почему:
1. Не везде он есть.
2. Внешняя зависимость, которая может сломать ГСЧ и он будет выдавать например одни единицы.


С другой стороны, достаточно мало кому нравится копаться в этом, обычно все используют всё стандартное, а здесь как видно спортивный интерес + любопытство. Ничего плохого я думаю нет.


Кстати, тема по ссылке в начале статьи всё ещё обсуждается на том форуме.

— sentaus (20/03/2016 23:23)   профиль/связь   <#>
комментариев: 1058   документов: 16   редакций: 32
натуральный (аппаратный) ГСЧ

/dev/urandom – это ГПСЧ

он будет выдавать например одни единицы.

Реальные временные метки – это не сильно далеко от единиц. А у автора-то есть какие-нибудь обоснования достоинств его велосипеда по сравнению со стандартными?
— pgprubot (20/03/2016 23:25)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

При чём здесь автор? Вопрос задаёте вы, а не автор. /dev/urandomсофтварный неблокируемый ГПСЧ, пополняемый из «хардварного» блокируемого /dev/random. Впрочем, насколько хардварен последний — не возьмусь судить. Матчасть была в комментариях [1], [2], смотрите по ссылкам.


В любой ОС он есть.


Уязвимость системного ГСЧ — настолько фатальная бага для настолько всего в системе, что целесообразно считать все велосипеды по её устранению заведомо бесполезными.


И это правильно. Стандартное хоть как-то худо-бедно обосновано, вылизано и проверено временем, в отличие от домашних велосипедов. Изобретать собственный ГСЧ — такое же фричество, как и делать собственный шифр или хэш.


Обезбаливающее можно купить в аптеке, ножики — в магазине, или сделать самим, а потом можно приступать к операциям на головном мозге. Все используют врачей и стандартных нейрохирургов, а здесь, как видно, спортивный интерес + любопытство. Ничего плохого, я думаю, нет.
— alexor1234 (21/03/2016 00:31, исправлен 21/03/2016 00:45)   профиль/связь   <#>
комментариев: 13   документов: 4   редакций: 1

Стойте, я совсем забыл, там речь вообще не о том, чтобы сделать свой ГСЧ, а получить каждый раз уникальные числовые последовательности, не обязательно не предсказуемые или секретные. Там связано с одноразовостью гаммы, а хеш берётся, чтобы скрыть MAC как минимум, вот в этом дело по сути получается.


Реальные временные метки – это не сильно далеко от единиц. А у автора-то есть какие-нибудь обоснования достоинств его велосипеда по сравнению со стандартными?

Насколько мне известно, все аргументы сводятся к тому, что если взять все MAC-адреса на одном ПК, которых может быть и не один, плюс добавить метку utc запуска программы, ещё добавить время работы системы по высокоточному таймеру в момент запуска проги, и при каждом запросе в конце делать инкремент +1 номера сеанса, то вся эта вещь никогда не совпадёт.
Правда, там туманно указано, что время не должно сильно откатиться назад, больше чем время запуска ОС, потому что есть теоретическая вероятность нарваться на тоже UTC, но ведь значение высокоточного таймера всё-равно не совпадёт, если только всё это не произошло в тот же миг, отсчитывая от времени работы ПК.


А ещё на вход добавляется сам ключ, чтобы нельзя было подобрать входные известные параметры и узнать адреса сетевых карточек или тайм-метки.


Хотя на выходе смотрится даже как ГСЧ, но не в этом суть.


Я просто хочу понять, любопытно даже, почему это нельзя использовать то?

— SATtva (21/03/2016 11:08)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Тогда вообще непонятно, зачем этот велосипед с 7 колёсами и седлом, торчащим из руля. Автор может использовать один монотонный счётчик (нормальная подстраховка — дополнить счётчик системным таймером, но ничего сверх этого не нужно). Учитывая, что в схеме есть некий секретный ключ, это уже гарантирует неповторяемость между экземплярами приложения.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3