Клуб любителей ASPLinux

А оно и сейчас там.
У тебя или у них с кукесами что-то случилось (я тоже не сразу смог войти).
Нужно войти через основной вход на сайт.

Виноват, думал, что ты о сайте forum.ru-board.com

Нет, не устроит
Добавлю: в подметки не годится

© Бюрократия - мать порядка
= ASPLinux 12/KDE =

Мы ушли на asplinuxclub.org - как не справивишиеся с обязанностями модераторов

А что по поводу GPG?
http://www.gnupg.org

Админ админу - друг, товарищ и ман...
(c) Almaty

Какой метод применяется в TSM?

Мы ушли на asplinuxclub.org - как не справивишиеся с обязанностями модераторов

Итак, господа, я вижу, что не все из вас достаточно хорошо знакомы с криптографией и криптоанализом; так что я выскажу свою точку зрения, основываясь, преимущественно, на прочтении более 2/3 (и переваривании прочтённого) бесцеллера Брюса Шнайера "Прикладная Криптография"; ну и на своём имхо, конечно.

В PGP действительно лет 5 назад нашли дыру, но это была ошибка реализации алгоритма RSA и её устранили, по крайней мере в GPG. Сам алгоритм RSA надёжен и проверен временем - последнее весьма важно, т.к. математической проверки алгоритма и даже открытости кода недостаточно - всё предусмотреть невозможно; и только годы успешного практического применения могут давать существенную вероятность надёжности алгоритма.

Я буду говорить о GPG, нет смысла обсуждать PGP, т.к. ей есть открытая альтернатива. В коде GPG само по себе шифрование (и реализация протоколов) вообще не выполняется - это делается на уровне библиотек openssl, которые используя вся Линуха. Полагаю, не следует серьёзно ставить их под сомнение, т.к. тогда вообще нет смысла говорить о криптографии под практически весь Unix. Конечно, в openssl могут быть (и, к сожалению, бывают) ошибки реализации, но их оперативно правят; а вот о преднамеренно заложенных уязвимостях говорить, полагаю, не стоит.

Так что единственное в чём можно попытаться обвинить авторов GPG - это в ослаблении ключей, вставки кусков определённого или случайного открытого теста и его шифртекста (полученного с использованием ключей пользователя) в искомый шифртест и т.п.. Но код GnuPG полностью открыт, а такие колоссальные изменения встроить незасеченными для общественности, часть которой регулярно эти коды проверяет, невозможно.

Итак, gpg - это то что проверено временем, обладает не только открытыми алгоритмами, но и открытой реализацией алгоритмов (исходники openssl) и открытой реализацией самого алгоритма программы.

А теперь посмотрим на Top Secret Messenger. Где его исходники??? Не исходники библиотек с алгоритмами шифрования, а исходники самой программы? Их нет! Я тоже могу налинковать к своей проге каких угодно библиотек, выполнить вызовы соответсвующих функций, а в реальности, в закрытом коде конечной программы, вставить все нужные мне лазейки, ослабления ключей и прочие уязвимости.

Кроме того, openssl и gpg пользуется уйма людей и обновления этих пакетов очень часты, а как часто обновляется TSM и нет ли лазеек в обновлениях?

Да о чём тут вообще можно говорить? Если хоть одина компонента криптосистемы закрыта, значит такая криптосистема вообще не должна рассматриваться, т.к. закрытый код == очень высокая вероятность лазейки,
т.к. производителю есть что скрывать.

Далее, рассотрим стойкость заявленных "алгоритмов".

1) ECC Field: Non-composite GF(2^m)
ECC field - ну да, поле эллиптических кривых, есть такое.
GF(2^m) - мультипликативная группа конечных полей характеристики 2. В действительности - это характеристика задачи дисретного логарифмирования и никем не доказано, что она математически сложнее чем разложение на множители, используемое в RSA; просто реализация дискретного логарифмирования действительно сложнее, но ассимптотики те же! Это обозначает только одно - красивые графики на http://www.encrsoft.com/products/tsm.html - это просто гон, если их группа полей действительно GF(2^m).

Мало того, в криптографии для полей эллептических кривых принято совсем иное обозначение: EC(F).

А вот это вообще полный (не буду выражаться что):
---
The library is using non-composite elliptic curves over GF(2^m), that have no known sup-exponential attacks against them.
---
Запомните: не существует алгоритмов, которые нельзя взломать (методом дифференциального или линейного криптоанализа, например) за время, большее, чем суперполиномиальное (это "экспоненцильное" время, где в показателе экспоненты стоит функция растущая медленнее, чем линейная), это подтверждается многодесятилетней практикой криптоанализа. В приведённом выше фрагменте написано прямо противоположное.

2) Digital Signature Primitive: Elliptic Curve DSA (ECDSA)
Да, существует такое. Вот только стойкость алгоритмов на эллептических кривых недоказана, непроверена, а лишь предполагается.

3) Symmetric Encryption Algorithms: Triple DES (FIPS/ANSI X9.52 Standards), AES (Rijndael)
За 3des пинать нужно ногами - этот алгоритм возможно взломать на современных мощьностях. Стандартам он пока что удовлетворяет лишь потому, что крепко въелся в бизнес-решения и запрет обойдётся слишком дорого; посмотрите, как долго и с каким трудом отзывали des.

AES - да, это вроде бы надёжная вещь, но и в openssl она есть.

4) Hash Function: SHA-1 (FIPS 180-1 Standard)
gpg не хуже, там аналогично.

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

Вывод (имхо):
Mimino, к сожалению, просто зря потратил деньги на раскрученный шерпотрёп, который использует непроверенные алгоритмы (и использует ли он их вообще?) и который, что хуже всего, обладает закрытой реализацией и в нём может быть втроено (и, скорее всего, встроено) что угодно.

Итог: люди, используйте старый-добрый gpg, openssl и радуйтесь жизни! Пусть опытные криптографы, пишущие эти программы, делают своё дело, подтверждая чистоту рук свободным кодом. И не ловитесь на всякую круто описанную (для человека малопосвящённого) фигню.

З.Ы. лично я для шифрования использую blowfish, придуманный самим Шнайером и aes, как на данный момент неплохо зарекомендовавший себя алгоритм, обладающий неплохой временной проверкой. ПО, разумеется, только с свободным кодом.

Per aspera ad astra!

Во..., и lystor почувствовал актуальность и пользительность темы...

А вот теперь бы все это - да в прикладную область...
Я так понимаю, у темы Skype+альтернативы может получиться серьезное развитие.
:good:

Админ админу - друг, товарищ и ман...
(c) Almaty

Да, так вот. Конечно, весьма интересный комментарий Bircopf, спасибо
Безусловно, открытый код - сильнейший аргумент в пользу доверия к продукту. Но в то же время может быть самым иезуитским способом получения такого доверия. Представьте, что взломан не продукт, а сам принцип криптования. В этом случае не нужно напрягать свои мозги и "Большие компьютеры" - сообщение не вскрывается методом перебора или поиска статистических зависимостей в сообщении, а декодируются в считанные миллисекунды по обратному, неизвестной широкой общественности, алгоритму.
И поэтому свободные криптографы могут годами ползать по исходному коду PGP и уверять, что в нем нет явных или скрытых бекдюр - и это действительно может быть так, на этом и строится расчет! - но "изюминка" может быть совсем не в этом.
И странная история с преследованием Циммермана, а затем его "прощение", переход PGP в руки Net Association и последующее закрытие исходного кода продукта, а затем, спустя некотрое время, снова открытие, пристальное внимание заинтересованных правительственных организаций к PGP под лозунгом "Не пущать!", а затем "Бери, не хочу!" - все это наводит на определеные размышления. Не зря опытные криптографы рекомндуют использовать PGP не выше 6.5 - что-то за этим кроется.
Вы как хотите, но доверять единственному продукту - это складывать яйца в одну корзину. Более надежно защищать информацию методом "матрешки" продуктами совершенно различных вендоров совершенно различных государств - и весьма желательно - с диаметральным политическим строем . Отлично для этого подходит, например, Беларусь :lol:, жаль лишь, что у них нет своих криптопродуктов.
Поэтому в данном случае TSM будет неплохой подпоркой для PGP, и наооборот.

© Бюрократия - мать порядка
= ASPLinux 12/KDE =