Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Опять:-) "Стойкость шифра зависит только от стойкости ключа!" К.Шеннон. 23.05.05 17:41 Число просмотров: 3736
Автор: Garick <Yuriy> Статус: Elderman
|
> Это вообще проблема в безопасности, а если при таких
> проблемах алгоритм стал известен сторонним лицам, то вообще
> писец.
Алгоритм используется ИМХО широизвестный, но особенно не рекламируется какой:-)
А вот утечка ключевой информации - это уже серьезно. И она могла произойти только на уровне топеров, но на это должны были отреагировать очень быстро.
Случайная последовательность также генериться крипто алгоритмом.
а функция должна выглядеть так: код_пополнения=функ (сер_нум, ключ_инфо). Вот узнать последний аргумент и есть "большая сложность".
|
|
<hacking>
|
У Киевстара увели базу скретч-карт? 23.05.05 10:45
Автор: amirul <Serge> Статус: The Elderman
|
Случился тут со мной казус.
Прислали СМС если хочешь увеличить пенис выиграть приз позвони по такому то телефону. Я ничего не теряя перезваниваю и мне говорят: купи карту пополнения на 100 или 300 грн ($20 и $60 соответственно) и перезвони. Ради бога, мне все равно пора пополняться, а что из этого выйдет - интересно. Покупаю, перезваниваю. Меня просят назвать СЕРИЙНЫЙ номер (тот который в открытую напечатан в правом нижнем углу). Я опять-таки, не чувствуя подвоха, сообщаю третьим лицам ОТКРЫТУЮ информацию. Меня просят подождать два часа - мне не сложно. Через два часа стираю защитное покрытие, пытаюсь пополниться, но карта уже активирована.
Самое интересное в реакции киевстара. Сказали, мол на фига вообще разговаривать с аферистами и на фига сообщать им КАКУЮ ЛИБО информацию. Я им: млять, да это не у меня обманом выудили секретную информацию, а у вас, но пострадали при этом не вы (деньги то я все равно уже заплатил), а я, так что я хочу получить свои деньги на свой счет. Ну дальше следует длинный прогон о том, что они не имеют возможности узнать какой телефон был пополнен с этой карты и вообще они не ведут никаких логов конфиденциальной информации и им вообще не интересно что У НИХ появилась огромная дыра в безопасности и разбираться они с этим не хотят, потому как на бабки кинули не их, а меня. Вот краткое содержание моего двадцатиминутного разговора с оператором
Защитное покрытие с карты стерто и она активирована, так что у меня нет никакой возможности самостоятельно добиваться справедливости. У киевстара нет никакого желания разбираться с собственными проблемами. Теперь собственно вопросы
1. НА ФИГА. Если кто-то владеет базой скретч карт, то какого @#$а просто не использовать первый попавшийся номер, а проворачивать какую то аферу с призами
2. ЧЕГО ДАЛЬШЕ. Лично я не вижу никакой возможности развить эту ситуации при явном нежелании киевстара этим заниматься и уже смирился с потерей $20 (честно говоря были и более весомые потери), но чем черт не шутит, может кто предложит куда бечь и что делать.
3. КАК оператор сотовой связи с ТАКИМ уровнем безопасности смог выйти на международный уровень? Сегодня воруют со скретч-карт, завтра обнаглеют и начнут воровать прямо со счетов (или звонить на 8-900-xxx-xx-xx с чужих телефонов)
|
|
Написал заявку о мошенничестве в региональном представительстве 17.06.05 12:21
Автор: amirul <Serge> Статус: The Elderman
|
Пришел ответ:
Да, бывает такая фигня, причем не только у нас (типа другие не лучше, и не надо к ним уходить). Мы никаких акций по скретчкартам не проводим (а мне по фигу кто проводит акцию - призы может не только киевстар раздавать). И не @#$ сообщать секретный код кому попало (МЛЯТЬ!!!! Они даже не читали мою заявку!!! Ну их на @#$)
Теперь вот сижу, рассматриваю варианты перехода на другого оператора.
|
| |
Сегодня в аську сбросили "похожую" историю 17.06.05 15:44
Автор: JINN <Sergey> Статус: Elderman
|
За достоверность не ручаюсь, типа "as is" :
You have received a message!
Автор: ZZZ
Дата: 17.06.05, @13:57
Вчера звонит мне на мабилу робот и от имени компании "Джинс" сообщает, что компьютер
выбрал мой номер случайным образом и я выиграл мобилу или путёвку в Египет на двоих
от компании "Гамалия" (стоимость 1100 у.е.). Чтобы стать счастливым обладателем, я должен связаться по высветившемуся номеру в течении 5 минут.
Связываюсь. Откликается девушка, типа менеджер по рекламе. Хорошо поставленным голосом рассказывает мне, что у них 10 призов (3 путёвки и 7 телефонов). Я должен купить карточку
пополнения на 80 грн, не активировать её и в течении часа перезвонить им, назвав любые
три цифры из кода пополнения. Также поинтересовалась, как меня зовут и моим адресом.
Что это развод, я догадался сразу же, но интересно стало, как они по трём произвольным цифрам угадают 14-значный код. Раньше, насколько я знаю, просто разводили на "утроение суммы", а тут технология развода изменилась. Перезваниваю товарищу в UMC, рассказываю прикол. Он меня расхолаживает, говорит что всё равно они меня будут раскручивать на весь код. В общем
сгенерил он мне код пополнения и стал я звонить жуликам снова.
Называю девушке три цифры. Она их типа "вводит в компьютер" и сообщает, что мне дико повезло
и я выиграл путёвку. Но могу взять деньгами 1100 долларов, спросила какой я банк предпочитаю, пообещала, что со мной свяжутся и вручат мне пластиковую карту. При себе иметь телефон,
карточку и удостоверение личности и бла-бла-бла. И тут ключевой момент: "А теперь, пожалуйста, продиктуйте весь ваш код пополнения, чтобы мы точно знали, что эта карточка у вас реальная и не активированная". Изображая лоха, диктую её весь код. Она попросила меня не использовать этот
код в течение двух дней, а затем курьер даст мне код, который утроит сумму.
На этом мы попрощались.
Сегодня утром обнаружилось, что вчера в 14 с копейками часов (через полчаса после разговора)
они пополнили этим ваучером счёт, причём не новый стартовый пакет, а некий старый
(действующий) джинсовский номер. Фишка в том, что ваучер, который я им продиктовал,
пополнял счёт на .... минус пятьсот гривень.
И вот они бедные уже больше суток ломятся в службу поддержки, где им наверняка ехидно
и вежливо советуют приехать к ним с карточкой и разобраться на месте.
Целый день отличное настроение. :-D
|
| | |
Здорово! Кидал кинули!!! 20.06.05 14:01
Автор: Den <Денис Т.> Статус: The Elderman
|
|
|
| | |
У-у-у, дорогой! А как ты мне настоение поднял! Спасибо! 8-) 18.06.05 08:26
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| | |
Мля, так м...в учить и надо, в минус их и прямым рейсом в Бобруйск 17.06.05 18:08
Автор: LOnG <LOnG> Статус: Member
|
|
|
| | | |
Если б операторы хоть немного озаботились этим вопросом 20.06.05 12:21
Автор: amirul <Serge> Статус: The Elderman
|
(А сейчас им это по фигу - мошенники вроде как повышают их доходы), то они бы вывесили на сайте форму и дали бы бесплатный сервисный SMS номер, при помощи которого можно было бы получить код пополнения на отрицательную (-$200 к примеру) сумму. Ясен пень, чистых лохов от этого меньше не станет, но это как с гражданским огнестрелом - никогда не ясно лох ли конкретно этот человек. Если хотя бы 5% будет знать об этом номере и пользоваться им (вести себя как будто повелся, а потом развести кидалу), то этот вид мошенничества ОЧЕНЬ БЫСТРО станет невыгодным.
Хотя с другой стороны, в моем случае у них вроде бы база скретч карт, но таких случаев вообще то очень мало
|
|
Мысли 23.05.05 14:43
Автор: Heller <Heller> Статус: Elderman
Отредактировано 23.05.05 14:46 Количество правок: 1
|
Во-первых, возможно, что базу не уводили, а виновата криптография. Конечно, маловероятно, но вполне возможно, что
секр_код=f(серийник)
Вдруг они решили таким образом экономить место на диске? (а дураков вообще-то много). Кто-то подглядел/разгадал функцию.
Вариант два, тоже математический: секретные коды генерятся случайно, но это псевдослучайные последовательности. Возможно, человек опять же разгадал функцию генератора (или подглядел) и теперь сидит дома и сам генерит карточки. Серийник в данном случае - номер элемента последовательности.
Ещё, как вариант, разгадывая ПСГ он нашёл способ узнать случайное значение по номеру эелемента в последовательности, минуя рекурсивные вычисления (а возможно он их и не знает).
Зачем человеку потребовался серийник, однако, это не объясняет. Только если действительно не хочет вызвать подозрений. Или боится активировать уже активированную карту (мало ли) - поэтому он хочет удостовериться, что карта свежая. С учётом того, что карт активированных ОЧЕНЬ много - опясения вполне обоснованы. Если бы он пропобовал все номера подряд - его бы точно накрыли.
Насчёт "что дальше". Попробуй изобразить Митника и обмануть девушку на телефоне, которая не соединяет с безопасниками. Скажи ей, что у тебя проблемы с GPRS, употреби умные термины - соединит обязательно. Никто ведь не заставляет тебя говорить правду девушке с ФАКом?
Или ещё красивый вариант. Покупай карту, звони "мошенникам", диктуй номер, но защитное поле не вскрывай! Идёшь в офис оператора и на глазах изумлённого персонала стираешь защитный слой и активируешь карту. Правда, если у "мошенников" произойдёт конкретно с данным номером накладка, то ты будешь выглядеть оригинально :-)
|
| |
Я тоже думал о том, что код может быть функцией серийника 23.05.05 16:56
Автор: amirul <Serge> Статус: The Elderman
|
Это вообще проблема в безопасности, а если при таких проблемах алгоритм стал известен сторонним лицам, то вообще писец.
> Насчёт "что дальше". Попробуй изобразить Митника и обмануть
> девушку на телефоне, которая не соединяет с безопасниками.
> Скажи ей, что у тебя проблемы с GPRS, употреби умные
> термины - соединит обязательно. Никто ведь не заставляет
> тебя говорить правду девушке с ФАКом?
Да я лучше наверное в региональное представительство подойду и там поругаюсь
> Или ещё красивый вариант. Покупай карту, звони
> "мошенникам", диктуй номер, но защитное поле не вскрывай!
Дважды в одну воронку... :-)
В смысле телефон мошенников уже не отвечает. Это был предоплаченный пакет и даже не киевстаровский.
> Идёшь в офис оператора и на глазах изумлённого персонала
> стираешь защитный слой и активируешь карту. Правда, если у
> "мошенников" произойдёт конкретно с данным номером
> накладка, то ты будешь выглядеть оригинально :-)
Лучше не стирать защитное покрытие, а позвонить в call-центр и поинтересоваться статусом данной карточки. Вот когда уже точно уверен, что карточка уже активирована можно и понятых созывать и протокол составлять. Вот только фиг аферисты позвонят мне еще раз
|
| | |
Опять:-) "Стойкость шифра зависит только от стойкости ключа!" К.Шеннон. 23.05.05 17:41
Автор: Garick <Yuriy> Статус: Elderman
|
> Это вообще проблема в безопасности, а если при таких
> проблемах алгоритм стал известен сторонним лицам, то вообще
> писец.
Алгоритм используется ИМХО широизвестный, но особенно не рекламируется какой:-)
А вот утечка ключевой информации - это уже серьезно. И она могла произойти только на уровне топеров, но на это должны были отреагировать очень быстро.
Случайная последовательность также генериться крипто алгоритмом.
а функция должна выглядеть так: код_пополнения=функ (сер_нум, ключ_инфо). Вот узнать последний аргумент и есть "большая сложность".
|
| | | |
Стойкость шифра определяется стойкостью шифровальщицы (с)... 24.05.05 09:42
Автор: cybervlad <cybervlad> Статус: Elderman
|
|
Стойкость шифра определяется стойкостью шифровальщицы (с) НКВД
|
| | | |
Шеннон вообще умный мужик был :-) 23.05.05 18:16
Автор: amirul <Serge> Статус: The Elderman
|
> > Это вообще проблема в безопасности, а если при таких
> > проблемах алгоритм стал известен сторонним лицам, то
> вообще
> > писец.
> Алгоритм используется ИМХО широизвестный, но особенно не
> рекламируется какой:-)
Имеется в виду, что "если при таких проблемах" алгоритм стал известен. То бишь если безопасность держалась только на неизвестности алгоритма, то было бы весьма плохо, если бы данный алгоритм "утек".
> а функция должна выглядеть так: код_пополнения=функ
> (сер_нум, ключ_инфо). Вот узнать последний аргумент и есть
> "большая сложность".
Как по мне, то лучше сделать вообще независимые серийник и код пополнения и все соответствия держать в базе. То есть функция то есть, но в целом она выглядит примерно так:
код_пополнения = select код_пополнения from база where сер_нум = запрошенный_сер_нум
Обычная табличная функция.
|
| | | | |
Я в оптимизации систем баз данных не большой спец, но мне кажется... 23.05.05 18:28
Автор: Garick <Yuriy> Статус: Elderman
|
> Как по мне, то лучше сделать вообще независимые серийник и
> код пополнения и все соответствия держать в базе. То есть
> функция то есть, но в целом она выглядит примерно так:
> код_пополнения = select код_пополнения from база where
> сер_нум = запрошенный_сер_нум
> Обычная табличная функция.
Я в оптимизации систем баз данных не большой спец, но мне кажется...
что для этого слишком большая вычислительная и дисковая мощность необходима.
1. запросы на верификацию кода пополнения.
2. извлечение суммы пополнения
3. установка статуса "активировано"
4. Добавление новых карточек и переиндексация после добавления.
5. Очистка не валидных карточек из базы (просроченная дата активации, например).
6. Отслежевание всех транзакций по базе с целью предотвращения подбора кодов недобросовестными сотрудниками или несанкционированного доступа.
добавлять можно еще.
|
| | | | | |
Есть такая структура B-Tree называется 23.05.05 19:07
Автор: amirul <Serge> Статус: The Elderman
|
Дает гарантированное логарифмическое время (для худшего случая) для операций поиска/вставки/удаления и оптимизирована для хранения баз данных на внешних носителях с посекторным чтением. А если еще и закешировать хотя бы пару уровней в этом дереве, то вообще мгновенная выборка получается.
> > Как по мне, то лучше сделать вообще независимые
> серийник и
> > код пополнения и все соответствия держать в базе. То
> есть
> > функция то есть, но в целом она выглядит примерно так:
> > код_пополнения = select код_пополнения from база where
> > сер_нум = запрошенный_сер_нум
> > Обычная табличная функция.
> Я в оптимизации систем баз данных не большой спец, но мне
> кажется...
> что для этого слишком большая вычислительная и дисковая
> мощность необходима.
Будем считать, что в каждый момент времени активно ~10-100 миллионов карточек. Если на каждую карточку нужно порядка 4 байт на серийник и 6 байт (14 десятичных разрядов) на код пополнения. Пусть оверхед на хранение - 200% (до фига на самом деле, ну да ладно - мне не жалко) итого 32 байта на каждую запись. Для хранения ВСЕЙ базы в памяти достаточно от 320 метров до 3.2 гига ОЗУ. Это вполне реально даже на персональных тачках (не думаю, что у КС нет денег на High-end сервак). Самая частая операция - поиск - будет выполняться вообще без доступа к диску.
> 1. запросы на верификацию кода пополнения.
Логарифмическое врямя (для худшего случая) поиска по дереву
> 2. извлечение суммы пополнения
В ноде для кажного значения хранится вся необходимая информация
> 3. установка статуса "активировано"
См. п. 2
> 4. Добавление новых карточек и переиндексация после
Логарифмическое (для худшего случая) время добавления в дерево
> добавления.
> 5. Очистка не валидных карточек из базы (просроченная дата
> активации, например).
Логарифмическое (для худшего случая) время удаления.
> 6. Отслежевание всех транзакций по базе с целью
Это никак не зависит от алгоритма сопоставления серийника с кодом пополнения
> предотвращения подбора кодов недобросовестными сотрудниками
> или несанкционированного доступа.
См. п. 6
> добавлять можно еще.
Следует учитывать также, что каждая нода может входить более, чем в одно дерево/список (для поддержания возможности поиска по разным ключам, но исключить необходимость переиндексации)
Посмотрите на индекс гугля и поймете, что хранение десятков-сотен миллионов целочисленных пар ключ-значение - вообще детская задача в современном вычислительном мире.
|
| | | | | | |
Зачем такие сложности? 24.05.05 01:04
Автор: Heller <Heller> Статус: Elderman
Отредактировано 24.05.05 01:25 Количество правок: 1
|
Достаточно просто создать массив из секретных ключей. Адрес, по которому лежит конкретный ключ, соответствующий серийнику, вычисляется как
серийник * N + S
где N - длинна секретного ключа + 1 (один бит идёт на запись статуса активации), а S - некоторое начальное смещение. С учётом того, что карт теоретически бесконечно много, конкретное S можно выбирать из таблицы в зависимости от
серийник div X
где X - размер одной партии серийников. С учётом того, что карточки работают только ограниченное время, способ достаточно эффективный - количество таких независимых массивов ограничено только небольшим числом (я думаю, не больше 20, хотя скорее всего меньше), а старые массивы по мере истечения сроков активации удаляются.
Кстати, при такой организации, вариант, когда секретный ключ - функция серийника, оказывается очень даже эффективным. Для хранения любой пары серийник-ключ достаточно только одного бита. Экономия действительно колоссальная. Возможно, что ставка делалась именно на это. Тогда для хранения инормации обо ВСЕХ ключах достаточно несколько мегабайт и тогда выбор массива в зависимости от
серийник div X
вообще не нужен. Массив будет всего один на все случаи жизни.
|
| | | | | | | |
Это называется хеш-таблица 24.05.05 10:22
Автор: amirul <Serge> Статус: The Elderman
|
> Достаточно просто создать массив из секретных ключей.
> Адрес, по которому лежит конкретный ключ, соответствующий
> серийнику, вычисляется как
> серийник * N + S
> где N - длинна секретного ключа + 1 (один бит идёт на
> запись статуса активации), а S - некоторое начальное
> смещение. С учётом того, что карт теоретически бесконечно
> много, конкретное S можно выбирать из таблицы в зависимости
> от
Дело в том, что карточки выпускаются ежедневно и так же ежедневно удаляются просроченные карточки. Использовать хеш-таблицу на все пространство серийников (12 десятичных разрядов) - никакой памяти не хватит. И это только на таблицу, нужно разместить еще сами данные. Вообще хеширование можно использовать для исключения нескольких начальных уровней в дереве, но на фига? 3 вместо 4-х? Ну дык при правильной организации хранения первые несколько уровней и так будут закешированы. И весь поиск будет вестись в памяти
> Кстати, при такой организации, вариант, когда секретный
> ключ - функция серийника, оказывается очень даже
> эффективным. Для хранения любой пары серийник-ключ
> достаточно только одного бита. Экономия действительно
> колоссальная. Возможно, что ставка делалась именно на это.
> Тогда для хранения инормации обо ВСЕХ ключах достаточно
> несколько мегабайт и тогда выбор массива в зависимости от
> серийник div X
Я не совсем понимаю, что мы тут экономим. Сейчас 1 Мб DDR-а стоит $0.10, может еще на спичках предложите экономить? Теряем мы помимо процессорного времени, занятого вычислением криптографических функций, БЕЗОПАСНОСТЬ. То есть то, ради чего все затевалось. Можете считать, что табличная организация - это ноль, заксоренный одноразовой гаммой (одноразовый блокнот) - самый стойкий из известных на сегодня методов шифрования.
|
| | | | | | | | |
Вообще - то серверная регистровая с ЕСС память от $0.25 за мб. При этом необходима избыточность, а это уже $0.50. 24.05.05 11:07
Автор: Garick <Yuriy> Статус: Elderman
|
Один из украинских операторов использует сановский кластер с солярисом. Для биллинга или обслуживания телекомун оборудования(контроллеров базовых станций) я не знаю. А это уже другой порядок цен.
Все не так просто как кажется. В спецификациях и интерфейсах телекомуникационного оборудования четко сказано о платформе. И даже если хватает хай-енд винтела, а подключить не получиться. Или с сервисным обслуживанием проблемы возникнут.
|
| | | | | | | | |
Могу ошибаться, но хэш-таблица, это когда каждому элементу... 24.05.05 11:01
Автор: Heller <Heller> Статус: Elderman
|
> Дело в том, что карточки выпускаются ежедневно и так же
> ежедневно удаляются просроченные карточки. Использовать
> хеш-таблицу на все пространство серийников (12 десятичных
> разрядов) - никакой памяти не хватит. И это только на
> таблицу, нужно разместить еще сами данные. Вообще
> хеширование можно использовать для исключения нескольких
> начальных уровней в дереве, но на фига? 3 вместо 4-х? Ну
> дык при правильной организации хранения первые несколько
> уровней и так будут закешированы. И весь поиск будет
> вестись в памяти
Могу ошибаться, но хэш-таблица, это когда каждому элементу структуры однозначно соответствует ключ, по которому его можно найти, причём этот самый ключ прописывается в структуре. В данном случае ключ у нас выпадает и по факту это всё же массив. Ну да не важно.
> Я не совсем понимаю, что мы тут экономим. Сейчас 1 Мб DDR-а
> стоит $0.10, может еще на спичках предложите экономить?
> Теряем мы помимо процессорного времени, занятого
> вычислением криптографических функций, БЕЗОПАСНОСТЬ. То
> есть то, ради чего все затевалось. Можете считать, что
> табличная организация - это ноль, заксоренный одноразовой
> гаммой (одноразовый блокнот) - самый стойкий из известных
> на сегодня методов шифрования.
Я же не сказал, что я бы стал так делать :-), я сказал, что возможно они руководствовались такими соображениями. Естесственно, если у них там сидят плохие безопасники (а возможно, они на эту должность забили, набрав простых программистов - такое тоже бывает). Плюс к объёму, мы на этом экономим вычислительные мощности (если учесть мою провалившуюсю гипотезу о том, что карточки выпускают достаточно редко). Вычисление средней хэш-функции гораздо быстрее, чем обход дерева, каким бы оно ни было.
Где мы теряем в безопасности опять же не ясно. Как я писал выше, даже если номера карт "случайны", они всё равно представляют из себя _псевдо_случайную последовательность, которая генерится рекурсивно. Эту рекурсивную процедуру можно либо угадать (маловероятно), либо подсмотреть. Прирост в безопасности для меня не очевиден.
Причём тут одноразовый блокнот не понял вовсе. Кстати, одноразовый блокнот - это не "самый стойкий из известных на сегодня", а "абсолютно стойкий на все времена" (если ключ случаен). Доказано Шенноном.
ЗЫ. Я вот ещё что подумал: взлома скорее всего не было и у них действительно просто украли базу или сунули стопку карточек в топограф. Они ведь просили купить только карточки определённого номинала, а не любую. Если бы это был взлом, то им было бы без разницы. Конечно, они могли расчитывать на то, что если требовать только определённые карточки, то это будет больше похоже на лотерею, либо они не захотели размениваться по мелочам, но мне это кажется маловероятным. (Хотя они могли расчитывать и на конкретный ход мыслей как у меня, что бы отвести внимание следствия от себя).
ЗЗЫ. Однако я подозреваю главным образом топ-менеджеров. Кому нужно СТОЛЬКО денег на мобильнике? Забрать-то их, как я знаю, нельзя. Единственный вариант - они забрать их всё же могут, а значит, это уже действия сотрудников компании.
|
| | | | | | | | | |
Ну в общем хеш таблица - это вырожденный индексный поиск 24.05.05 15:38
Автор: amirul <Serge> Статус: The Elderman
|
> Могу ошибаться, но хэш-таблица, это когда каждому элементу
> структуры однозначно соответствует ключ, по которому его
> можно найти, причём этот самый ключ
> прописывается в структуре. В данном
> случае ключ у нас выпадает и по факту это всё же массив. Ну
> да не важно.
Когда все пространство ключей (а в нашем случае это 10^12 ключей) покрыть не получается, покрывается только часть этого пространства. Ну соответственно область поиска сужается
Ну да. В принципе не важно. Я тоже мог неправильно понять твою идею. Просто при беглом просмотре я решил, что если есть таблица а все пространство ключей не покрывается, то покрывается только его часть. А это и есть хеш-таблица
> Я же не сказал, что я бы стал так делать :-), я сказал, что
> возможно они руководствовались такими
> соображениями. Естесственно, если у них там сидят плохие
> безопасники (а возможно, они на эту должность забили,
> набрав простых программистов - такое тоже бывает). Плюс к
> объёму, мы на этом экономим вычислительные мощности (если
> учесть мою провалившуюсю гипотезу о том, что карточки
> выпускают достаточно редко). Вычисление средней хэш-функции
> гораздо быстрее, чем обход дерева, каким бы оно ни было.
Ну насчет гораздо - это слишком громко сказано. Если в каждой ноде B-tree будет храниться скажем 256 ключей, то самый длинный путь - 6 нод, из которых первых пару-тройку уровней скорее всего будут в кеше.
> Где мы теряем в безопасности опять же не ясно. Как я писал
> выше, даже если номера карт "случайны", они всё равно
Увести БАЗУ сложнее, чем увести ключ.
> представляют из себя _псевдо_случайную последовательность,
> которая генерится рекурсивно. Эту рекурсивную процедуру
> можно либо угадать (маловероятно), либо подсмотреть.
Есть такая штука, как пул энтропии. Достаточно на каждом шаге использовать пару (а лучше десяток-полтора) бит из этого пула и подбор становится невозможным уже через несколько шагов рекурсии. Ну а сам пул энтропии можно собирать как на одном компьютере так и в сетке с клавиатур, мышей, сетевых адаптеров, винчестеров, линейных входов аудиоплат, температурных датчиков и пр..
> Прирост в безопасности для меня не очевиден.
> Причём тут одноразовый блокнот не понял вовсе. Кстати,
> одноразовый блокнот - это не "самый стойкий из известных на
> сегодня", а "абсолютно стойкий на все времена" (если ключ
> случаен). Доказано Шенноном.
Длина ключа равна длине базы кодов пополнения (если они достаточно случайны). Как свести к каноническому блокноту - это не ко мне :-)
> карточки, то это будет больше похоже на лотерею, либо они
> не захотели размениваться по мелочам, но мне это кажется
> маловероятным. (Хотя они могли расчитывать и на конкретный
> ход мыслей как у меня, что бы отвести внимание следствия от
> себя).
На фига это им нужно для меня тоже самая загадочная часть во всей этой истории
> ЗЗЫ. Однако я подозреваю главным образом топ-менеджеров.
> Кому нужно СТОЛЬКО денег на мобильнике? Забрать-то их, как
> я знаю, нельзя. Единственный вариант - они забрать их всё
> же могут, а значит, это уже действия сотрудников компании.
Во первых не все карточки сливаются на один и тот же телефон. Во вторых у киевстара есть услуга перевод денег. Можно обменивать виртуальные деньги на реальные по курсу 2/1 например.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
