Можно ли использовать такие источники для кода сеанса?
На сайте был вопрос про альтернативные источники для создания кода сеанса:
http://www.cyberforum.ru/crypt.....y/thread1678074.html
Вместо использования аппаратного генератора СЧ, наподобие RdRand, предлагается использовать время запуска программы по системному времени UTC, время запуска программы ещё по времени работы ПК (высокоточный таймер), и номер текущего сеанса.
Аппаратный ГСЧ не устроил автора за его не повсеместное распространение и за внешнюю зависимость.
Всё это даёт 24 байта кода сеанса.
Утверждается, что он никогда не совпадёт в пределах того же ПК, если только время не откатится слишком сильно назад (превышающее время запуска ОС), и то вероятность совпадения всё также мала.
Для уникальности в пределах всех ПК было предложено добавить физический адрес сетевых карт, имени компьютера и другое, естественно пропустив это через хеш-функцию.
Нормально ли так делать? Первый вариант предлагает вообще не пропускать ничего через хеш-функцию, раскрывая системное время запуска программы и проработанное компьютером время на момент запуска программы.
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 13 документов: 4 редакций: 1
Наверно желание самому контролировать процесс. Однако вещь довольно таки любопытная, и походу дела всё упирается в поддержание точного системного времени для теоретического несовпадения. Чтобы не было совпадений на разных ПК используется MAC адрес, но так ли физический адрес уникален, как считается?
То что это велосипедостроение было давно понятно, автору нравится это, вопрос лишь в том, как у него это получается.
комментариев: 271 документов: 0 редакций: 0
Не совсем по теме, но есть вопрос.
Пытаюсь запустить точку доступа на debian7 с помощью hostapd. При попытке запуска происходит завис на том, что не хватает энтропии /dev/random. Где прописать чтобы обращение шло в /dev/urandom?
комментариев: 11558 документов: 1036 редакций: 4118
Почему бы тогда не подбрасывать монетку?
Он и не считается уникальным. В нём в лучшем случае 64 бита данных, значительная часть из которых вообще предсказуемы: идентификатор изготовителя, идентификатор типа и модели устройства и т.д. (Задача MAC-адреса в том, чтобы быть уникальным, а не случайным.) Но главное в том, что MAC-адрес не является сколь-нибудь секретным, он всегда передаётся в сеть и всегда в открытом виде.
комментариев: 271 документов: 0 редакций: 0
Добавлю, и легко подменяем.
комментариев: 13 документов: 4 редакций: 1
У автора выбор стоит, либо пропускать ключ, MAC адрес и время запуска программы по двум таймерам (utc, hightimer) через хеш-функцию, либо не пропускать, но если не пропускать через хеш, то смущает раскрытие посторонним время запуска и самого MAC адреса, так ли это страшно?, тем более что с приходом IPv6, где последние 64 бита – это и есть физический адрес, его раскрытие неизбежно.
Но повторюсь, у автора цель с помощью всего этого получить только лишь неповторимую числовую последовательность для кода сеанса.
Я например, даже не могу сказать, какой вариант мне больше нравится, так как пропускание всего этого через хеш может дать теоретическую коллизию, хотя наверно при достаточно большой длине это в принципе не должно волновать и может быть аргументом только в теории, но не в практике.
комментариев: 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 или других виртуальных адаптеров.
комментариев: 11558 документов: 1036 редакций: 4118
Автор ставит ошибочную дилемму. Нет никакой разницы, хэшируются входные данные ГПСЧ или нет, если сами входные данные предсказуемы или их можно достаточно быстро перебрать.
Что такое "код сеанса"? Nonce для криптопараметров? Или просто какой-то случайный идентификатор для сессии пользователя на веб-сайте?
комментариев: 13 документов: 4 редакций: 1
Как я понял, это сделать не получиться, потому что на вход подаётся секретный ключ Key. Входные данные хешируются, потому что автор не хочет их раскрывать посторонним.
Как я понял, это просто идентификатор сессии, чтобы выходная гамма была каждый раз разной.
комментариев: 11558 документов: 1036 редакций: 4118
И мы возвращаемся к первому вопросу: зачем этот странный велосипед, если можно использовать стандартную конструкцию HMACk(R), где R — вывод из /dev/urandom?
комментариев: 13 документов: 4 редакций: 1
Автору не нравится натуральный (аппаратный) ГСЧ вот почему:
1. Не везде он есть.
2. Внешняя зависимость, которая может сломать ГСЧ и он будет выдавать например одни единицы.
С другой стороны, достаточно мало кому нравится копаться в этом, обычно все используют всё стандартное, а здесь как видно спортивный интерес + любопытство. Ничего плохого я думаю нет.
Кстати, тема по ссылке в начале статьи всё ещё обсуждается на том форуме.
комментариев: 1060 документов: 16 редакций: 32
/dev/urandom – это ГПСЧ
Реальные временные метки – это не сильно далеко от единиц. А у автора-то есть какие-нибудь обоснования достоинств его велосипеда по сравнению со стандартными?
комментариев: 511 документов: 2 редакций: 70
При чём здесь автор? Вопрос задаёте вы, а не автор. /dev/urandom — софтварный неблокируемый ГПСЧ, пополняемый из «хардварного» блокируемого /dev/random. Впрочем, насколько хардварен последний — не возьмусь судить. Матчасть была в комментариях [1], [2], смотрите по ссылкам.
В любой ОС он есть.
Уязвимость системного ГСЧ — настолько фатальная бага для настолько всего в системе, что целесообразно считать все велосипеды по её устранению заведомо бесполезными.
И это правильно. Стандартное хоть как-то худо-бедно обосновано, вылизано и проверено временем, в отличие от домашних велосипедов. Изобретать собственный ГСЧ — такое же фричество, как и делать собственный шифр или хэш.
Обезбаливающее можно купить в аптеке, ножики — в магазине, или сделать самим, а потом можно приступать к операциям на головном мозге. Все используют врачей и стандартных нейрохирургов, а здесь, как видно, спортивный интерес + любопытство. Ничего плохого, я думаю, нет.
комментариев: 13 документов: 4 редакций: 1
Стойте, я совсем забыл, там речь вообще не о том, чтобы сделать свой ГСЧ, а получить каждый раз уникальные числовые последовательности, не обязательно не предсказуемые или секретные. Там связано с одноразовостью гаммы, а хеш берётся, чтобы скрыть MAC как минимум, вот в этом дело по сути получается.
Насколько мне известно, все аргументы сводятся к тому, что если взять все MAC-адреса на одном ПК, которых может быть и не один, плюс добавить метку utc запуска программы, ещё добавить время работы системы по высокоточному таймеру в момент запуска проги, и при каждом запросе в конце делать инкремент +1 номера сеанса, то вся эта вещь никогда не совпадёт.
Правда, там туманно указано, что время не должно сильно откатиться назад, больше чем время запуска ОС, потому что есть теоретическая вероятность нарваться на тоже UTC, но ведь значение высокоточного таймера всё-равно не совпадёт, если только всё это не произошло в тот же миг, отсчитывая от времени работы ПК.
А ещё на вход добавляется сам ключ, чтобы нельзя было подобрать входные известные параметры и узнать адреса сетевых карточек или тайм-метки.
Хотя на выходе смотрится даже как ГСЧ, но не в этом суть.
Я просто хочу понять, любопытно даже, почему это нельзя использовать то?
комментариев: 11558 документов: 1036 редакций: 4118
Тогда вообще непонятно, зачем этот велосипед с 7 колёсами и седлом, торчащим из руля. Автор может использовать один монотонный счётчик (нормальная подстраховка — дополнить счётчик системным таймером, но ничего сверх этого не нужно). Учитывая, что в схеме есть некий секретный ключ, это уже гарантирует неповторяемость между экземплярами приложения.