Когда можно доверить себя для реализации основанных на криптографии решений?

Практическое правило криптографии не в том, что вы не должны использовать его, если вы ' ты не эксперт; скорее, вам не следует изобретать колесо заново, если вы не являетесь экспертом. Другими словами, максимально используйте существующие реализации / библиотеки / алгоритмы. Например, не пишите свой собственный алгоритм криптографической аутентификации и не придумывайте еще один способ хранения ключей.

Что касается , когда его использовать: всякий раз, когда у вас есть данные, которые необходимо защитить от чтобы другие видели это. Помимо этого, все сводится к тому, какие алгоритмы / подходы лучше всего: SSL против IPsec против симметричного против PKI и т. Д.

Также небольшой совет: управление ключами часто является самой сложной частью любого всеобъемлющего криптографического решения. .

всякий раз, когда у вас есть данные, которые необходимо защитить от просмотра другими. Помимо этого, все сводится к тому, какие алгоритмы / подходы лучше всего: SSL против IPsec против симметричного против PKI и т. Д.

Также небольшой совет: управление ключами часто является самой сложной частью любого всеобъемлющего криптографического решения. .

всякий раз, когда у вас есть данные, которые необходимо защитить от просмотра другими. Помимо этого, все сводится к тому, какие алгоритмы / подходы лучше всего: SSL против IPsec против симметричного против PKI и т. Д.

Также небольшой совет: управление ключами часто является самой сложной частью любого всеобъемлющего криптографического решения. .

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

То же самое и с требованиями к безопасности, но дополнительная сложность заключается в том, что для создания любого вида специального решения требуются дополнительные знания технических групп (разработка, поддержка и т. Д.). Существует также проблема, что решение должно быть не только безопасным, но и распознаваться как безопасное . Этого может быть намного проще достичь с помощью готового решения.

И RickNZ абсолютно прав - не забывайте об управлении ключами. Считайте это с самого начала частью процесса принятия решений.

У вас все наоборот: сначала вы должны подробно указать свои фактические требования («предоставить решение безопасности» - бессмысленная маркетинговая чушь). Затем вы ищете способы удовлетворить эти конкретные требования; Кроптография удовлетворит некоторые из них.

Пример требований, которым может удовлетворять криптография:

• Защищать данные, передаваемые по общественным каналам, от шпионажа
• Защищать данные от подделки (или, скорее, обнаруживать манипулируемые данные)
• Разрешить серверы и клиенты и пользователи, чтобы доказать друг другу свою личность

Я бы хотел начать с вопроса: чего вы пытаетесь достичь?
Если вы пытаетесь просто защитить передачу данных с сервера a на сервер b, вы можете использовать ряд механизмов, которые потребуют небольшой работы, например SSL.
Однако, если вы пытаетесь защитить все данные, хранящиеся в приложении, что намного сложнее, хотя, если это является обязательным требованием, я бы предложил, чтобы любая криптография, независимо от того, насколько легко взломать, лучше, чем ничего.

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

Здесь нет абсолютных значений, все относительно.

Почему покупают криптографию? Это одна из наиболее развитых областей в области программного обеспечения с открытым исходным кодом и отличного качества :) См., Например, TrueCrypt или OpenSSL

. Есть хороший шанс, что все, что вам нужно, криптография уже есть. качественный, уважаемый проект с открытым исходным кодом для этого! (И если вы видите источник, вы можете увидеть, что они сделали; однажды я видел статью о коммерческом программном обеспечении, которое должно «шифровать» файл, который просто xorred каждый байт с фиксированным значением!)

И, кроме того, почему Вы бы хотели заново изобрести колесо? Маловероятно, что без опыта криптографии вы добьетесь большего успеха или даже приблизитесь к текущим алгоритмам, таким как AES.

Я думаю, это полностью зависит от того, чего вы пытаетесь достичь.

Нужно ли хранить данные в зашифрованном виде на обоих концах или их просто нужно зашифровывать во время передачи?

Как вы передаете данные? FTP, HTTP и т. Д.?

Наверное, не стоит использовать безопасность в качестве второй фазы, поскольку к этому моменту вы, вероятно, в течение некоторого времени перемещали данные небезопасно?

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

Внедрение криптографической системы очень сложно, и эксперты обычно ошибаются как в теории, так и на практике. Известным теоретическим провалом была ранцевая криптосистема, от которой в значительной степени отказались из-за алгоритма редукции решеточного базиса Ленстры – Ленстры – Ловаса. С другой стороны, в прошлом году мы видели, как неправильное начальное число в генераторе случайных чисел Debian открывало любой ключ, сгенерированный ОС. Вы хотите использовать заранее подготовленную криптосистему не потому, что это поле «только для экспертов», а потому, что вам нужна система, протестированная и поддерживаемая сообществом. Почти каждый известный мне криптографический алгоритм имеет границы, которые предполагают, что определенные задачи являются сложными, и если эти задачи оказываются вычислимыми (как в алгоритме LLL), вся система становится бесполезной за ночь.

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

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

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

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