От Офф-Топик
К Офф-Топик
Дата 05.09.2002 02:37:44
Рубрики Прочее; Современность; Спецслужбы; Космос;

Алгоритм шифрования ТЕЛЕМЕТРИИ в 60-70 годы

Valeriy B
Начинающий

N 22
создано 12-04-2001 08:47
--------------------------------------------------------------------------------
Чтобы оценить состоятельность второго предположения - о несанкционированном вводе команд, нужно иметь самое общее представление о принципах шифрования телеметрии. Вот, в общих чертах, как это делалось на заре развития цифровых технологий.
В дешифратор вводится, для определенности, двадцатиразрядное десятичное число, содержащее в зашифрованном виде некую команду или параметр. Оно поступает на вход столбца содержащего, допустим, 10 разных гладких функций скомбинированных из элементарных. За первым столбцом находится другой, содержащий те же самые или другие функции, за ним - третий столбец функций. За последним находится маска, определяющая какие разряды полученного на выходе двадцатиразрядного десятичного числа являются носителями собственно кода команды.

Каждая из функций имеет два (или более) двадцатиразрядных коэффициента, которые вводятся в процедуре авторизации дешифратора, непосредственно перед передачей пакета команд, в кодах авторизации содержится также ключи, задающие рабочую функцию из первого столбца, выход с этой функции будет подан на один из входов второго столбца - определяется следующим ключом , то же для третьего столбца функций, плюс код маски. Таким образом, количество различных процедур кодировок в такой схеме будет: 10 ^ 20 задаются первым коэффициентом первой функции, 10 ^ 20 - вторым коэффициентом первой функции, далее по два коэффициента для одной из функций второго и третьего столбцов, плюс три ключа имеющих по 10 направлений - это еще 10 ^ 3. Всего получается
(10^20)*(10^20)*(10^20)*(10^20)*(10^20)*(10^20)*(10^3) = 10 ^ 123.
Это число на много порядков больше возраста Вселенной, выраженном даже не в секундах, а в квантах элементарного времени. Таким образом, постановка задачи о дешифрировании сообщения посторонними является в строгом смысле антинаучным актом.

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

Итак, второе объяснение неудач марсианских экспедиций можно изъять из рассмотрения с не меньшими основаниями, чем первое.



--------------------------------------------------------------------------------
Сообщений: 95 | IP: записан

Anatoly
Модератор

N 28
создано 12-04-2001 09:29
--------------------------------------------------------------------------------
Валерий, речь шла не о несанкционированном вводе команд, а об элементарной ошибке оператора! Она есть или ее нет, независимо от способа шифрования и дешифровки.
--------------------------------------------------------------------------------
Сообщений: 692 | IP: записан

От Игорь Скородумов
К Офф-Топик (05.09.2002 02:37:44)
Дата 05.09.2002 09:46:39

Re: Не зарекайся!(+)


В случае, если алгоритм китайца по простым числам верен - ХАТА ЭТОМУ ПОДХОДУ!

С уважением
Игорь
P.S. Эбо простой перебор используют от того, что не знают алгоритм генерации простых чисел и поэтому не могут выделить закономерности в псевдослучайных последовательностях.
От tarasv
К Игорь Скородумов (05.09.2002 09:46:39)
Дата 05.09.2002 10:52:10

Re: А можно подробней?

> В случае, если алгоритм китайца по простым числам верен - ХАТА ЭТОМУ ПОДХОДУ!

Чтото я недопонял какое отношение к описанномй алгоритму имеют простые числа.
От Игорь Скородумов
К tarasv (05.09.2002 10:52:10)
Дата 05.09.2002 13:11:00

Re: А можно...


>> В случае, если алгоритм китайца по простым числам верен - ХАТА ЭТОМУ ПОДХОДУ!
>
> Чтото я недопонял какое отношение к описанномй алгоритму имеют простые числа.
 Если взять за основу сообщение офф-топика
=====================================
Каждая из функций имеет два (или более) двадцатиразрядных коэффициента, которые вводятся в процедуре авторизации дешифратора, непосредственно перед передачей пакета команд, в кодах авторизации содержится также ключи, задающие рабочую функцию из первого столбца, выход с этой функции будет подан на один из входов второго столбца - определяется следующим ключом , то же для третьего столбца функций, плюс код маски. Таким образом, количество различных процедур кодировок в такой схеме будет: 10 ^ 20 задаются первым коэффициентом первой функции, 10 ^ 20 - вторым коэффициентом первой функции, далее по два коэффициента для одной из функций второго и третьего столбцов, плюс три ключа имеющих по 10 направлений - это еще 10 ^ 3. Всего получается
(10^20)*(10^20)*(10^20)*(10^20)*(10^20)*(10^20)*(10^3) = 10 ^ 123.
==========================================

И предположить, что супостат смог найти алгоритм расчета коэфициентов, то вся наша модель летит к черту. То есть алгоритм перескока должен быть СЛУЧАЙНЫМ. Для этого используют псевдослучайные последовательности на основе простых чисел. Так как алгоритма генерации простых чисел пока нет, это гарантирует, что супостату придется искать ответ лобовым перебором.

С уважением
Игорь
От tarasv
К Игорь Скородумов (05.09.2002 13:11:00)
Дата 05.09.2002 13:29:59

Re: А можно...

> И предположить, что супостат смог найти алгоритм расчета коэфициентов, то вся наша модель летит к черту.

Если считать что алгоритм известен то да.

>То есть алгоритм перескока должен быть СЛУЧАЙНЫМ. Для этого используют псевдослучайные последовательности на основе простых чисел.

Почему именно простых? Вот в чем вся суть моего вопроса. Они по алгоритму там не ИМХО требуются. Это обычный шифр преобразования типа того-же DES. В случае конечного ключа берется, при бесконечном ключе не берется принципиально.
От AMX
К tarasv (05.09.2002 13:29:59)
Дата 05.09.2002 17:04:18

Re: А можно...


>> И предположить, что супостат смог найти алгоритм расчета коэфициентов, то вся наша модель летит к черту.
>
> Если считать что алгоритм известен то да.

Алгоритм скорее всего известен и даже сильно не скрывается. Просто вычисление ключа на основе перехваченных данных займет время сильно большее полета МБР и поэтому бессмысленно. Поэтому скорее всего вычисление простых чисел по алгоритму китайца врядли чего даст.
От Игорь Скородумов
К tarasv (05.09.2002 13:29:59)
Дата 05.09.2002 15:39:21

Re: А можно...


>> И предположить, что супостат смог найти алгоритм расчета коэфициентов, то вся наша модель летит к черту.
>
> Если считать что алгоритм известен то да.

>>То есть алгоритм перескока должен быть СЛУЧАЙНЫМ. Для этого используют псевдослучайные последовательности на основе простых чисел.
>
> Почему именно простых? Вот в чем вся суть моего вопроса. Они по алгоритму там не ИМХО требуются. Это обычный шифр преобразования типа того-же DES. В случае конечного ключа берется, при бесконечном ключе не берется принципиально.

Офф-топик привел расчет количества переборов при ЛОБОВОМ ломании шифра. Использование простых чисел заставляет использовать ТОЛЬКО ЛОБОВОЙ вариант!
При использовании в качестве коэффициентов НЕ простых чисел данная функция оптимизируется (за счет расклада сложных чисел на простые). Соответственно формула расчета количества вариантов уменьшается и стойкость шифра падает. То есть вместо тупого перебора ключей можно попробовать расчитать формулу генерации ключа. (Как собственно и взломали Энигму).

С уважением
Игорь
От Роман Алымов
К tarasv (05.09.2002 10:52:10)
Дата 05.09.2002 10:53:14

Наверное как составные части матриц (-)
От Игорь Скородумов
К Роман Алымов (05.09.2002 10:53:14)
Дата 05.09.2002 13:11:23

Re: Правильно(-)
От Venik
К Офф-Топик (05.09.2002 02:37:44)
Дата 05.09.2002 03:02:44

Re: Алгоритм шифрования...

Мое почтение!

>Таким образом, постановка задачи о дешифрировании сообщения посторонними является в строгом смысле антинаучным актом.

Нет такого антинаучного акта для которого IBM бы не построила суперкомпьютер :)

С уважением, Venik
От Алексей
К Venik (05.09.2002 03:02:44)
Дата 05.09.2002 06:23:17

Re: Алгоритм шифрования...


>Мое почтение!

>>Таким образом, постановка задачи о дешифрировании сообщения посторонними является в строгом смысле антинаучным актом.
>
>Нет такого антинаучного акта для которого IBM бы не построила суперкомпьютер :)


Все правильно. только нехватает оценки времени. 3DES - они, конечно "щелкают", 1024бит - вроде "крякали" сообча. Но вот выше - напряженка со временемю Точнее противоречие - за время "кряка" информация обесценивается временем....


>С уважением, Venik

Взаимно.
От Venik
К Алексей (05.09.2002 06:23:17)
Дата 05.09.2002 20:01:08

Ре: Алгоритм шифрования...

Мое почтение!

>Все правильно. только нехватает оценки времени. 3ДЕС - они, конечно "щелкают", 1024бит - вроде "крякали" сообча.

3DES и я на домашнем компе крякаю. Когда я в университете учился, у студентов в обшежитии был такой бизнес: у всеx, разумеется были компьютеры и широкий канал, и они обьеденили все компы для параллельной обработки кодированыx файлов - всякие там Word, zip, регистры виндов и пр. ерунда. $45 баксов за пароль который крякается в среднем за несколько минут.

У IBM все-же иные возможности... :-)

С уважением, Веник
От Алексей
К Venik (05.09.2002 20:01:08)
Дата 05.09.2002 21:20:22

Ре: Алгоритм шифрования...


>Мое почтение!

>>Все правильно. только нехватает оценки времени. 3ДЕС - они, конечно "щелкают", 1024бит - вроде "крякали" сообча.
>
>3DES и я на домашнем компе крякаю.


Наверно у вас в компе штук 128 процессороа.
В противном случае - врядли.
На традиционном компе можно крякнуть DES-56 (и то. придется - подождать)



Когда я в университете учился, у студентов в обшежитии был такой бизнес: у всеx, разумеется были компьютеры и широкий канал, и они обьеденили все компы для параллельной обработки кодированыx файлов - всякие там Word, zip, регистры виндов и пр. ерунда. $45 баксов за пароль который крякается в среднем за несколько минут.


Это немножко не то.


>У IBM все-же иные возможности... :-)


Конечно. Кроме того, у нее есть знание слвбых сторон DES-56? 3DES и AES ( впротивном случае - его бы не делали интернациональным)


>С уважением, Веник
От Venik
К Алексей (05.09.2002 21:20:22)
Дата 06.09.2002 01:22:53

Ре: Алгоритм шифрования...

Мое почтение!

>Наверно у вас в компе штук 128 процессороа.
>В противном случае - врядли.
>На традиционном компе можно крякнуть DES-56 (и то. придется - подождать)

Да вроде всего два процессора, но может меня надули в магазине? :))

Я это делал в плане эксперимента: закодировал небольшой текстовый файл в PGP в triple-DES и крякнул его за две недели. Возможно пароль был короткий.

Больше всего трудностей мне доставили кодированные Word 2000 файлы. У меня было несколько десятков файлов - вероятно все закодированные одним и тем-же паролем. Но программа, которую я использовал, не позволяла найти пароль, хоть и открывала файлы. Т.ч. на каждый файл уходилo 3-5 дней, правда на 400MHz Пентиуме.

С уважением, Venik
От AMX
К Venik (05.09.2002 20:01:08)
Дата 05.09.2002 20:28:40

Ре: Алгоритм шифрования...

>>Все правильно. только нехватает оценки времени. 3ДЕС - они, конечно "щелкают", 1024бит - вроде "крякали" сообча.
>
>3DES и я на домашнем компе крякаю. Когда я в университете учился, у студентов в обшежитии был такой бизнес: у всеx, разумеется были компьютеры и широкий канал, и они обьеденили все компы для параллельной обработки кодированыx файлов - всякие там Word, zip, регистры виндов и пр. ерунда. $45 баксов за пароль который крякается в среднем за несколько минут.

Во всех вышеперичесленных реализациях(Word, zip, регистры виндов и пр. ерунда) таки использовались пробелы в реализации. Между тем при знании недостатков и достоинств реализации замучались бы вы "крякать". Советую попробовать крякнуть например короткий, зазипованный файл с достаточно длинным паролем, количество "подходящих" паролей сделает вашу затею малопривлекательной и не быстро осуществимой.

>У IBM все-же иные возможности... :-)

У нее могут быть какие угодно возможности. Для ряда задач достаточно небольшого запаса по времени. Врядли кого нибуть устроит вычисление ключей к летящей сейчас МБР завтра к вечеру.
От muxel
К AMX (05.09.2002 20:28:40)
Дата 06.09.2002 09:50:21

Ре: Алгоритм шифрования...

Здравствуйте!

>У нее могут быть какие угодно возможности. Для ряда задач достаточно небольшого запаса по времени. Врядли кого нибуть устроит вычисление ключей к летящей сейчас МБР завтра к вечеру.

А какая критичность по времени при расшифровке телеметрии? Ну расшифруют ее не через день, а через неделю... Это если конечно не применяется шифровние с гарантированной стойкостью.

Всего самого и т.д....
От Venik
К AMX (05.09.2002 20:28:40)
Дата 05.09.2002 22:43:00

Ре: Алгоритм шифрования...

Мое почтение!

>Советую попробовать крякнуть например короткий, зазипованный файл с достаточно длинным паролем, количество "подходящих" паролей сделает вашу затею малопривлекательной и не быстро осуществимой.

Я крякал ZIP файл с паролем в 14 знаков (правда все цифры). За 10 дней на Пентиуме 933MHz.

В Ворде 2000, например, вообсче подобрать пароль - дело безнадежное, но дешифровать файл всё равно можно.

С уважением, Веник
От AMX
К Venik (05.09.2002 22:43:00)
Дата 06.09.2002 00:34:49

Ре: Алгоритм шифрования...

>>Советую попробовать крякнуть например короткий, зазипованный файл с достаточно длинным паролем, количество "подходящих" паролей сделает вашу затею малопривлекательной и не быстро осуществимой.
>
>Я крякал ZIP файл с паролем в 14 знаков (правда все цифры). За 10 дней на Пентиуме 933MHz.


Еще раз. Главное условие сам файл должен быть маленьким. В этом случае подходящих паролей получается просто огромное количество, а правильный только один.

Это только дилетант думает, что криптосистемы используют только как непробиваемую систему у которой ключ надо долго искать.
Можно использовать тот же эффект как и у алгоритма, использовавшегося в pkzip на маленьких файлах - огромное количество ключей будут давать один и тот же хэш, но при попытке расшифровать неправильным ключом ничего хорошего не получится. В этом случае время нахождения ключа не имеет никакого значения, т.к. будет на руках куча фиктивных ключей при попытке использования которых "зажется лампочка".
От Venik
К AMX (06.09.2002 00:34:49)
Дата 06.09.2002 01:06:35

Ре: Алгоритм шифрования...

Мое почтение!

>Еще раз. Главное условие сам файл должен быть маленьким. В этом случае подходящих паролей получается просто огромное количество, а правильный только один.

Когда я еще учился в университете, я использовал програмку pkcrack, вроде так она называлась, для открывания кодированных pkzip файлов.

Даже по стандартам 1993-94-го эти файлы были маленькими. pkcrack элементарно перебирает пароли, читая их из словаря. Это могут быть либо просто слова из английского словаря либо разные комбинации слов с цифрами. Я также пользовался небольшой программкой написанной в Korn-shell для генерации этих словарей, что позволяло сделать процесс эквивалентным "brute force attack" или поиску по маске.

Правда это занимало уйму времени и не всегда срабатывало. Но я в данной области не эксперт, т.ч. наверняка допускал грубые ошибки.

С уважением, Venik
От Ktulu
К Venik (05.09.2002 20:01:08)
Дата 05.09.2002 20:27:32

Не перепутали, случайно?


>Мое почтение!

>>Все правильно. только нехватает оценки времени. 3ДЕС - они, конечно "щелкают", 1024бит - вроде "крякали" сообча.
>
>3DES и я на домашнем компе крякаю. Когда я в университете учился, у студентов в обшежитии был такой бизнес: у всеx, разумеется были компьютеры и широкий канал, и они обьеденили все компы для параллельной обработки кодированыx файлов - всякие там Word, zip, регистры виндов и пр. ерунда. $45 баксов за пароль который крякается в среднем за несколько минут.

Именно 3DES? А с каким количеством ключей?
Или имелся в виду стандартный DES (56 бит который)?

--
Алексей
От Venik
К Ktulu (05.09.2002 20:27:32)
Дата 05.09.2002 22:38:01

вроде не перепутал

Мое почтение!

>Именно 3ДЕС? А с каким количеством ключей?
>Или имелся в виду стандартный ДЕС (56 бит который)?

3DES закодированный через PGP

С уважением, Веник