[quote name='Данилка'] Но иногда (щакономерность пока не определил), он сохраняет его так, что его можно открыть другим паролем. Естесственно, он не расшифровывается, тест заполнится не может. Не в этом суть. При нормальных обстоятельствах, когда программе для расшифровке подсовывают неверный ключ, генерируется исключение, которое можно обработать как “Неверный пароль”. Но в некоторых ситуациях при подсовывании неверного ключа это исключение не генерируется и программа думает, что все произошло правильно.Я в панике, кто-нибудь работал с криптографией? [/quote]В программе есть ряд недочетов, не касающихся криптографией и являющихся потенциальным источником проблем:Окно с паролем позволяет выходить из него, предоставляя работу программе без укаания пароля (обработчики нажатия “красивого крестика” в углу панели с паролем и клавиш Esc и Enter в текстовом поле с паролем).Далее есть недостаточная инкапсуляция – расшифровка полученного зашифрованного объекта вызывается из интерфейса и в интерфейсе же обрабатывается ошибка расшифровки, что не есть правильно.Кстати, это общая ошибка всей программы – привязанность к интерфейсу.Далее по коду:строка objRND.Create.GetNonZeroBytes(IV)должна выглядеть так:Security.Cryptography.RandomNumberGenerator.Create.GetNonZeroBytes(IV)В процедуре Encrypt ты в catch закрываешь объект fs, что вообще неверно, т.к. вызовется рантайм-эксепшн NullPointerException.В Decrypt та же ошибка в finally.В SaveTest два блока Try, следующих друг за другом и во втором вызов процедуры шифрования, не инициализарованной переменной, что есть потенциальная ошибка.Замучался уже анализировать 😉 . Такое количество ошибок само по себе уже должно вызывать нестабильность работы программы. Выдели тест в отдельный класс с криптографией. А из интерфейса зови методы.
