Систем, каким-либо образом защищенных от полного перебора на локальных данных, я не встречал, если честно, и слабо себе представляю возможность существования такой системы.
И да, физическая невскрываемость клиента и сервера — тоже разные вещи. Физически вскрыв сервер, вы не получите открытых текстовых заметок. Физически вскрыв клиент — тоже. Вопрос «кому сервер отдаст зашифрованные заметки, ключ к которым потенциальный злоумышленник сможет попытаться подобрать» — это уже вопрос аутентификации и авторизации, это совсем другая часть системы, которую вполне можно усовершенствовать.
А как тогда по-вашему расшифровывать-то, если клиент не будет знать алгоритма? Серверу полностью доверять и открытые данные? Тут тогда еще больше «точек отказа» будет.
подобрать ключ конкретного пользователя несложно
В одной работе Шнайера определено понятие криптографической стойкости:
1. Алгоритм является криптографически стойким, если не существует каких-либо методов его вскрытия, кроме метода «грубой силы» (brute force);
2. Кроме того, размер ключа алгоритма является достаточно большим для того, чтобы метод грубой силы стал невозможным при текущем уровне развития вычислительной техники.
Если использовать хороший симметричный алгоритм, и хорошую функцию деривации ключа из пароля, то перебор будет максимально затруднен, и останется только он. Методом перебора подобрать можно практически все, и похоже, что это нормально. А как еще-то?
Здесь Вы, кажется, путаете криптографическую защиту данных заметок и аутентификацию пользователя (вследствие которой он и получает некий набор зашифрованных заметок). Это разные вещи, и для достижения некоторой степени защищенности в каждой из них применяются разные методы. Систему аутентификации пользователя и авторизации его для получения своего набора зашифрованных заметок можно совершенствовать, и это не связано с методом хранения самих заметок.
Обратимся снова к указанному Вами первому принципу.
Система должна быть физически, если не математически, невскрываемой;
Здесь есть «если». А некоторую степень математической невскрываемости мы обеспечим использованием правильно спроектированной системы хороших, стойких алгоритмов, разве не так?
Снова обратимся к статье; на этот раз к той ее части, где высказана, пожалуй, самая соль этого принципа:
Принцип Керкгоффса направлен на то, чтобы сделать безопасность алгоритмов и протоколов независимой от их секретности; открытость не должна влиять на безопасность.
Второй пункт говорит фактически о том же:
Нужно, чтобы не требовалось сохранение системы в тайне; попадание системы в руки врага не должно причинять неудобств;
Если подвести итог моих дилетантских излияний, то получаем следующее: конечно можно закрыть алгоритм на сервере, но это скорее больше ухудшит безопасность, потому что тогда сервер будет знать и открытые тексты заметок. Закрытие алгоритма конечно может слегка затруднить жизнь взломщику, но полагаться только на эту черту системы нельзя. Более того, если не видно других способов, кроме закрытия системы на сервере, то как мы ее будем потом «опенсорсить», как предложил автор, опять же для повышения уровня доверия к системе?
Как избежать ситуации, когда я ввел неверный пароль, получил нечитаемую кашу в заметке, и сохранил ее обратно на сервер?
Можно хранить не хеш или иную удостоверяющую последовательность для пароля, а оную для заметки (и хранить ее также в зашифрованном виде вместе с заметкой, конечно). Или (afaik так делается в RAR) генерировать N случайных байт, считать от них хеш, и шифровать на том же пароле (т.е. делать «мини-заметку для валидации», которая пользователю не видна; сходно с первым вариантом). Или валидировать, что «полученные данные — текст в такой-то кодировке» средствами js на стороне клиента.
Использование только антивируса сегодня не дает практически никакой защиты. Воспользовались бы комплексом антивирус + фаервол + проактивная защита-HIPS (или вы им и пользовались?)
Я переключился на уязвимости ядра, но ведь вы обозначили в условиях только его, поэтому я и написал, что «а ведь кроме ядра у нас еще есть куча окружения, которое тоже вполне может быть уязвимо.», просто потому, что в условиях задачи ничего не было сказано об окружении.
Данный руткит — может и да, но мы же не только о нем, верно?
Понятно. Для успокоения сих личностей могу сказать, что я и сам на Linux — и на десктопах, и на серверах, однако не могу понять, откуда берется такая уверенность «мою систему невозможно взломать, она абсолютно защищена».
Т.е. вы утверждаете, что взлом невозможен, и ваша система абсолютно защищена? Вот это меня и удивляет — откуда такая уверенность?
Допустим примем Ваши условия. Гугл подсказал, что grsecurity — тоже не панацея (например jon.oberheide.org/blog/2011/04/20/stackjacking-your-way-to-grsec-pax-bypass/). Возьмем CVE-2010-2959, который «2.6.32.x before 2.6.32.21». Или там 1337day.org/exploit/14601. Ну или, раз у вас >=, тот же приснопамятный CVE-2012-0056 (mempodipper). Или там CVE-2012-2136. Да вот, выбирайте на вкус и условия например здесь. И это — только то, что нашлось сразу. А ведь кроме ядра у нас еще есть куча окружения, которое тоже вполне может быть уязвимо.
Вы поймите: не поверите — но я тоже на Linux. Однако тешить себя тем, что «мою систему невозможно взломать» — помоему это наивно, даже вредно.
И да, физическая невскрываемость клиента и сервера — тоже разные вещи. Физически вскрыв сервер, вы не получите открытых текстовых заметок. Физически вскрыв клиент — тоже. Вопрос «кому сервер отдаст зашифрованные заметки, ключ к которым потенциальный злоумышленник сможет попытаться подобрать» — это уже вопрос аутентификации и авторизации, это совсем другая часть системы, которую вполне можно усовершенствовать.
Посмотрите на zerobin :)
В одной работе Шнайера определено понятие криптографической стойкости:
1. Алгоритм является криптографически стойким, если не существует каких-либо методов его вскрытия, кроме метода «грубой силы» (brute force);
2. Кроме того, размер ключа алгоритма является достаточно большим для того, чтобы метод грубой силы стал невозможным при текущем уровне развития вычислительной техники.
Если использовать хороший симметричный алгоритм, и хорошую функцию деривации ключа из пароля, то перебор будет максимально затруднен, и останется только он. Методом перебора подобрать можно практически все, и похоже, что это нормально. А как еще-то?
Здесь Вы, кажется, путаете криптографическую защиту данных заметок и аутентификацию пользователя (вследствие которой он и получает некий набор зашифрованных заметок). Это разные вещи, и для достижения некоторой степени защищенности в каждой из них применяются разные методы. Систему аутентификации пользователя и авторизации его для получения своего набора зашифрованных заметок можно совершенствовать, и это не связано с методом хранения самих заметок.
Обратимся снова к указанному Вами первому принципу.
Здесь есть «если». А некоторую степень математической невскрываемости мы обеспечим использованием правильно спроектированной системы хороших, стойких алгоритмов, разве не так?
Снова обратимся к статье; на этот раз к той ее части, где высказана, пожалуй, самая соль этого принципа:
Второй пункт говорит фактически о том же:
Если подвести итог моих дилетантских излияний, то получаем следующее: конечно можно закрыть алгоритм на сервере, но это скорее больше ухудшит безопасность, потому что тогда сервер будет знать и открытые тексты заметок. Закрытие алгоритма конечно может слегка затруднить жизнь взломщику, но полагаться только на эту черту системы нельзя. Более того, если не видно других способов, кроме закрытия системы на сервере, то как мы ее будем потом «опенсорсить», как предложил автор, опять же для повышения уровня доверия к системе?
Алгоритм и должен быть известен
Можно хранить не хеш или иную удостоверяющую последовательность для пароля, а оную для заметки (и хранить ее также в зашифрованном виде вместе с заметкой, конечно). Или (afaik так делается в RAR) генерировать N случайных байт, считать от них хеш, и шифровать на том же пароле (т.е. делать «мини-заметку для валидации», которая пользователю не видна; сходно с первым вариантом). Или валидировать, что «полученные данные — текст в такой-то кодировке» средствами js на стороне клиента.
Как бы не так. Есть, например, уязвимости браузера, плагинов, etc.
Скорей смартфон говорит ПК, что он — роутер, а роутеру — что он ПК.
В импорте остается только GetTickCount64.
Я переключился на уязвимости ядра, но ведь вы обозначили в условиях только его, поэтому я и написал, что «а ведь кроме ядра у нас еще есть куча окружения, которое тоже вполне может быть уязвимо.», просто потому, что в условиях задачи ничего не было сказано об окружении.
Данный руткит — может и да, но мы же не только о нем, верно?
Допустим, и что? Тогда плюсуем сюда уязвимости из раздела «code execution», например, да и все.
Допустим примем Ваши условия. Гугл подсказал, что grsecurity — тоже не панацея (например jon.oberheide.org/blog/2011/04/20/stackjacking-your-way-to-grsec-pax-bypass/). Возьмем CVE-2010-2959, который «2.6.32.x before 2.6.32.21». Или там 1337day.org/exploit/14601. Ну или, раз у вас >=, тот же приснопамятный CVE-2012-0056 (mempodipper). Или там CVE-2012-2136. Да вот, выбирайте на вкус и условия например здесь. И это — только то, что нашлось сразу. А ведь кроме ядра у нас еще есть куча окружения, которое тоже вполне может быть уязвимо.
Вы поймите: не поверите — но я тоже на Linux. Однако тешить себя тем, что «мою систему невозможно взломать» — помоему это наивно, даже вредно.