В дополнение к замечательному ответу Томаса Порнина, вы также должны учитывать то, что вы пытаетесь достичь с точки зрения «безопасности» (конфиденциальность / целостность / подлинность / доступность).
В каждом случае вам нужно ответить на несколько вопросов, например ... К кому это относится? Где и почему он используется (что вы защищаете)? Как долго это должно длиться? и т.д.
Например, вероятно, нет смысла действительно шифровать данные сеанса с полной последовательностью 256-битных операций, когда данные действительно должны длиться, скажем, 20-30 минут. Безопасный 128-битный алгоритм будет почти вдвое быстрее или, по крайней мере, будет использовать нагрузку меньше тактов и будет таким же (если не больше) безопасным.
Также нет смысла шифровать что-то, что рассчитано на длительное время (например, конфиденциальный документ или файл, закрытый ключ и т. Д.), Используя метод слабого короткого ключа. Время от времени вам потребуется несколько алгоритмов с некоторой аутентификацией и правильным использованием отступов. Я регулярно шифровал и подписывал контент по запросу клиентов, используя несколько алгоритмов (в основном, twofish, AES, RSA).
И чтобы не забыть (как указывал Томас), вы можете небезопасно реализовать безопасный метод (или методы). С огромным количеством вариантов каждой формулы и тому подобным может быть сложно реализовать что-то «безопасное».
Как правило, что-то так же безопасно, как ключ, чтобы разблокировать его. Если я оставлю ключи от машины в машине с разблокированной машиной, ключи не будут в безопасности, и они будут открыты для взятия каждым, кто проходит мимо. Blowfish с хорошо распределенным ключом из 32 символов будет таким же безопасным, как и все остальное сегодня. Однако 3-символьная клавиша может быть сломана в мгновение ока.