GoSecure

qscwdvefb

Во-первых, не всё так просто, как Вы думаете.
Пароли - это не ключ, а его часть. Вторая часть ключа - это специально обработанные случайные данные. Эти данные - это изображение + дополнительные, независимые случайные числа.

Во-вторых, Вы ведёте неправильные рассуждения. Длина паролей - это не длина ключа. Также не забывайте, что паролей два - и оба могут быть по 20 символов. И подбирать нужно оба, а не один. Дальше. Можно подбирать либо ключ, либо пароли. Если ключ - то тут 256 бит, всё понятно. Если пароли - посчитайте, сколько может быть комбинаций при длине в 20 символов.

И наконец - Вы будете использовать пароли длинее, чем 20 символов?

По Вашим предложениям:

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

Не совсем понятно, что именно Вы имеете в виду. Размер изображения? Инструменты для рисования?

2. также генерация ключа не только программой, но и самим человеком

Опять же, очень интересно. Создание ключа - это не просто подбор чисел.

3. длина ключа должна быть произвольной длины, и поддерживать не меннее, чем 32 символа

Как уже было сказано, длина паролей - это не длина ключа. Пароли могут быть и по 3 символа, но тем не менее ключ - 256 бит.

Интерес

На конец месяца запланирован выпуск версии для Windows Vista, без каких либо новых возможностей. После этого - выпуск новой версии, с новыми возможностями! Но конкретных сроков относительно неё мы называть пока не будем.

А bug tracking и done things - это конфиденциальная информация, мы не можем Вам её предоставить.

All

В программе Secure Disk используются ключи размером 32 байта (256 бит).

1. Изображение может быть и внешним, например, файл с фотографией.

У нас была такая мысль. Но мы отказались от неё по той причине, что по смыслу изображение должно быть случайным, и не существовать после создания ключа. Если использовать фото - нельзя же быть уверенным, что злоумышленник не сможет им воспользоваться.
Хотя, опционально, использовать внешнее изображение можно.

2. Возможность придумывания 256-битного (то есть 32 символа) ключа и самим пользователем

Всё дело в том, что алгоритм генерации ключа - это не такая простая вещь, как может показаться на первый взгляд.
Ключ - это не просто случайные числа, взятые из паролей и например изображения. Данные ключа получаются методом обработки исходных, случайных данных (у нас это изображение) с помощью специальных алгоритмов.
Поэтому, нельзя просто так придумать последовательность чисел и сказать что вот это ключ.
Отсюда сразу понятно - ввод с клавиатуры отпадает. Тем более, что не всё множество знаков (0-255) может быть введено с клавиатуры простым набором.

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

Тут мы с Вами согласны. Однозначно нужен какой-то способ обезопасить себя. Сегодня можно делать бекапы хранилища. Но было бы неплохо иметь возможность записать ключ как Вы говорите на бумаге, или просто запомнить (что, правда, непросто). Несомненно мы подумаем над этим, как именно это лучше сделать, так чтобы было логично и безопасно. И в том или ином виде это обязательно будет в новой версии.

Спасибо Вам за желание помощь и советы.

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

Интерес написал:

скоро ли новый билд программы?

Планируется в последних числах августа - начале сентября.

Относительно надежности парольной авторизации пользователей советую почитать эту статью:
https://www.pgpru.com/biblioteka/statji … maparolejj

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

Boris написал:

Использовать PRTK и прочие приемы в предзагрузочной аутентификации весьма проблематично по той простой причине, что операционной системы нет, как нет и тех файлов, на базе которых можно организовать атаку. Да и с незагрузочными дисками ситуация не очень "приятная". У Вас зашифрован не отдельный файл, а целый диск.

Не представляет большой проблемы создание программы подбора паролей, учитывающей алгоритм авторизации именно Secure Disk. Будьте уверены, что если Secure Disk достигнет определенного порога популярности, появление такой программы не заставит себя долго ждать несмотря на закрытые исходники. А дальше вообще все просто - зашифрованный диск подключается к другому компьютеру с этой программой и запускается процесс перебора паролей по словарю или полным перебором. Благо любой чисто программный алгоритм авторизации не исключает возможность автономного перебора паролей. Единственное чем здесь можно осложнить жизнь злоумышленнику - реализовать в алгоритме замедление перебора паролей, как описано в вышеназванной статье.

Boris написал:

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

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

Boris написал:

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

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