информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Новая криптосхема передачи паролей с EuroCrypt 2001 25.05.01 17:19  
Автор: paganoid Статус: Member
<"чистая" ссылка>
Мне нужна информация о новой схеме парольной аутентификации, которая была недавно выдвинута на EuroCrypt 2001 .

Прочитал о ней здесь:
http://www.computerra.ru/cgi/yandmarkup?HndlQuery=1967431040&PageNum=0&g=0&d=0

В общем, идея этой схемы такая.

Сейчас обычно пароль шлётся от клиента на сервак плейнтекстом, там от него берётся хеш, сравнивается с хранящимся и даёт решение пущать/не пущать. Если есть доступ на чтение к серваку - пароль мы не поимеем. Если можем прослушать канал - то поимеем.
А вот тут штука, которая меня заворожила своей простотой и элегантностью. Клиент берёт от пароль ДЛИННЫЙ хэш, из него случайным образом берёт некоторые байты, компонует их в одну строку. От этой строки снова берёт обычный хэш. На сервак шлёт этот хэш и номера байтов длинного хэша, которые передает. Сервак получает эти номера, берёт у себя от хешу их, тож компонует, берет второй хэш , и сравнивает с тем, что получил. Т.е. по сетке ТОЛЬКО в одном направлении передаётся неповторяющийся (ну , Цэ из Эн по Ка может быть, но строка длинная!) хэш!
Т.е. даже подслушиванием линии мы ничего не добъемся.
Вобщем, если кто понял, что я имел в виду, то можно заметить, что не нужны никакие ассиметричные алгоритмы, центры хранения ключей, системы запрос-ответ и т.п. Кррасота!

ну итак, внимание на табло, вопрос: подскажите криптографическую ф-ю , которая генерит длинные хэш-строки по входному паролю. Также буду рад инфе по этой статье на Eurocrypt. В сети ее не нашел... :(
Что-то я с утра туплю... 27.05.01 14:50  
Автор: prop Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Мне нужна информация о новой схеме парольной
> аутентификации, которая была недавно выдвинута на
> EuroCrypt 2001 .
>
> Прочитал о ней здесь:
> http://www.computerra.ru/cgi/yandmarkup?HndlQuery=196743104
> 0&PageNum=0&g=0&d=0
>
Линка ета дохлая

> В общем, идея этой схемы такая.
>
> Сейчас обычно пароль шлётся от клиента на сервак
> плейнтекстом, там от него берётся хеш, сравнивается с
> хранящимся и даёт решение пущать/не пущать. Если есть
> доступ на чтение к серваку - пароль мы не поимеем. Если
> можем прослушать канал - то поимеем.
> А вот тут штука, которая меня заворожила своей простотой
> и элегантностью. Клиент берёт от пароль ДЛИННЫЙ хэш, из
> него случайным образом берёт некоторые байты, компонует их
> в одну строку. От этой строки снова берёт обычный хэш. На
> сервак шлёт этот хэш и номера байтов длинного хэша, которые
> передает. Сервак получает эти номера, берёт у себя от хешу
> их, тож компонует, берет второй хэш , и сравнивает с тем,
> что получил. Т.е. по сетке ТОЛЬКО в одном направлении
> передаётся неповторяющийся (ну , Цэ из Эн по Ка может быть,
> но строка длинная!) хэш!

А как сервер понимает, что "хэш" неповторяющийся? Он что, хранит
все предыдущие посылки для каждого юзеря ? Допустим, но все равно
есть вероятность, что посылка повторится - тогда сервер пошлет
нах легального пользователя.

> Т.е. даже подслушиванием линии мы ничего не добъемся.

Почему? Исходный пароль, возможно, мы не узнаем, но он и не нужен -
чо перехватили то серверу и пошлем.

> Вобщем, если кто понял, что я имел в виду, то можно
> заметить, что не нужны никакие ассиметричные алгоритмы,
> центры хранения ключей, системы запрос-ответ и т.п.
> Кррасота!
>

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

Извини, если понял тебя неправильно - тогда растолкуй.
Либо ты чего-то недорасказал (поскольку ссылка не работает сам прочитать не могу), либо это туфта.

> ну итак, внимание на табло, вопрос: подскажите
> криптографическую ф-ю , которая генерит длинные хэш-строки
> по входному паролю. Также буду рад инфе по этой статье на
> Eurocrypt. В сети ее не нашел... :(
Я ее тоже не нашел. В том числе на компьютерре.
Не надо :) 28.05.01 13:40  
Автор: paganoid Статус: Member
<"чистая" ссылка>
> Вообще после всех преобразовний все равно получаем
> хэш-функцию от пароля, но с параметрами - номерами байтов.
> Но эти параметры передаются в сообщении - чем это лучше-то?
>

Ну смотри. Мы каждый раз передаём РАЗНЫЕ наборы байтов, прально? Соотвецна, и каждый раз передаётся НОВЫЙ хэш. Ну и посему перехват ентаво хеша ничего не даст. На самом деле, я ищу побольше инфы по этой схеме - в журнале все очень обще описано. Не знаю, как они решают проблему запрета передачи двух одинаковых наборов (это видимо, как раз то, про что ты говоришь.) Соотвецна , хочется узнать. Либо они на сервере держат списки уже переданных наборов и запрещают передавать повторы, либо как-то в алгоритме эти номерки в хеш укатывают. Или..

> Извини, если понял тебя неправильно - тогда растолкуй.

Да я и сам не очень :) Просто чем мне это нравится - эту схему реализовать с использованием CGI наверно просто. На клиенте JavaScript а там - что угодно.

> Либо ты чего-то недорасказал (поскольку ссылка не работает
> сам прочитать не могу), либо это туфта.
>
> > ну итак, внимание на табло, вопрос: подскажите
> > криптографическую ф-ю , которая генерит длинные
> хэш-строки
> > по входному паролю. Также буду рад инфе по этой статье
> на
> > Eurocrypt. В сети ее не нашел... :(
> Я ее тоже не нашел. В том числе на компьютерре.

Сделай на компьютерре поиск по фамилиям Ostrovsky Katz .
Вот у меня открываеца все ок по ссылке

http://www.computerra.ru/cgi/yandmarkup?HndlQuery=1887041568&PageNum=0&g=0&d=0

Заголовок новости - "Размер здесь не главное"
Спасибо, нашел 28.05.01 16:52  
Автор: prop Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ну по такой статье вообще чего-либо понять тяжело - писал ее человек либо безграмотный, либо журналист (что для медицины эквивалентно). Мне, например, понравилась фраза "..... их (функций) обратное вычисление невозможно, если вычисляющему заранее не известен ответ". Что имелось ввиду понять можно, но если автор написал такое - всему остальному доверять сложно.
Доклад на евокрипте достаточно свежий, и на оф. сайте еврокрипта он только обозначен в программе. Я думаю, детали алгоритма опубликуют, когда, сделают какой-нибудь продукт его использующий - дабы хапнуть немного бабла. Поживем (почаще) - увидим.
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach